La pile graphique du Raspberry Pi est aujourd’hui intégralement libre. C’est ce qu’annonce AlexBradbury sur le blog de la fondation à l’initiative du projet.
Le développeur affirme que le BCM2835 embarqué sur le Raspberry Pi est le premier système sur puce d’architecture ARM à disposer de pilotes libres pleinement fonctionnels fournis par le fabricant.
Mise à jour du 25 octobre : Il semble que l’annonce d’une libération de la pile graphique ne soit en réalité qu’un coup publicitaire de Broadcom et de la fondation Raspberry Pi. Selon Luc Verhaegen et Dave Airlie le code libéré n’est qu’une mince couche qui se contente de faire appel au binaire tournant dans le processeur graphique.
NdM : Le Raspberry Pi est un ordinateur de la taille d’une carte de crédit et dont le prix de vente lors de son lancement était de 25 euros. Vous trouverez quelques retours des lecteurs de LinuxFr.org sur ces pages.
Participants à la rédaction de cette dépêche : weeber, Nÿco et Benoît.
Ceci a été rendu possible grâce à la diffusion sous licence BSD de toutes les bibliothèques permettant d’utiliser la puce de Broadcom. Cette dernière est en charge aussi bien du rendu 3D que des opérations d’encodage et de décodage vidéo.
Ainsi, la prise en charge d’OpenGL pour le rendu 3D, d’OpenVG pour le vectoriel et d’OpenMax pour le multimédia est maintenant entièrement basée sur du code libre.
Ceci devrait notamment faciliter l’implémentation de Wayland sur le célèbre ordinateur. Cela permettra également de faciliter le développement des pilotes libres tels que Mesa 3D sur d’autres plates‐formes équipées du même processeur graphique. Cependant, certaines parties sont implémentées directement en langage assembleur spécifique au videocore.
Après avoir annoncé que son ordinateur serait fabriqué au Royaume‐Uni et non plus en Chine, la fondation continue de soigner son image de marque. En évoquant plusieurs systèmes d’exploitation qui pourraient bénéficier de cette avancée (FreeBSD, NetBSD, Plan9, RISC OS et Haiku), elle se positionne comme un contributeur important au logiciel libre.
Aller plus loin
- L’annonce de la fondation Raspberry Pi (209 clics)
- Le code source des bibliothèques sur GitHub (160 clics)
- Made in the UK (70 clics)
# Et les sources du gros firmware qui gère le GPU?
Posté par Benjamin Henrion (site web personnel) . Évalué à 9.
Et les sources du gros firmware qui gère le GPU, elles sont ou?
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Voir sur LWN http://lwn.net/Articles/520930/
C'est clair que cette annonce semble un peu pipeau car bien bridée par une API.
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par reno . Évalué à 4.
Je ne suis pas d'accords: ils ont annoncé qu'ils ont libéré leur pilote. C'est ce qu'ils ont fait, POINT, donc ce n'est pas du pipeau (ne pas confondre pilote et firmware).
Corollaire: tout le code tournant sur l'ARM peut maintenant être open-source, et conséquence positive OpenBSD devrait pouvoir être porté sur Raspberry Pi.
Après leur pilote est pour des accéder des interfaces "haut niveau" fournie par le GPU (qui a un compilateur embarqué) et non pas des interfaces "bad niveau":
1) ça rends ces pilotes beaucoup plus figés et plus fragile, ce que tu appelle (correctement) "bridé".
2) c'est moins intéressante pour ceux qui aiment bien "mettre les mains dans le cambouis"
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par neerd . Évalué à 9.
La nouvelle a d'ailleurs été très chaleureusement accueillie par le leader charismatique d'OpenBSD.
http://marc.info/?l=openbsd-misc&m=135109499020826&w=2
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par reno . Évalué à 0.
Mouai sauf que la "closed source backend" tourne sur un autre processeur.
Mais j'aurai du m'en douter: Téo est plus sensible à l'esprit qu'à la lettre..
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par FluffyHamster . Évalué à 0.
Non, le "firmware" qui est enfaîte un driver complet, et non pas un "firmware" au sens conventionnel du terme (blob qu'on charge et qui sera exécuté dans la mémoire d'une puce séparée) ne tourne pas sur le GPU mais bien sur le CPU. Il est néanmoins probable que le firmware charge lui aussi un vrai firmware dans le GPU pour réaliser certaines fonctions.
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par Narishma Jahar . Évalué à 1.
C'est faux. Le firmware (blob propriétaire) tourne sur le GPU et ne touche pas le CPU à part pour le démarrer. Quand tu allumes to Raspberry Pi, c'est le GPU qui s'occupe de tout initialiser avant de booter et de donner la main au CPU.
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par FluffyHamster . Évalué à 0.
Un GPU n’exécute pas de code, il n'a aucun moyen de magiquement charger un blob. On envoie des commandes à un GPU par l'intermédiaire du kernel, commandes qui dérivent des fonctions d'une API (opengl et compagnie) et c'est le driver qui traduit les appels opengl en commandes que le GPU comprends.
Même les shaders sont compilés (translation glsl / hlsl / gc >> un unique langage spécifique à un GPU) par le driver (qui s’exécute encore une fois dans le CPU) avant d'envoyer le tout au GPU.
Se référer à comment fonctionne mesa et autres piles de drivers sur un PC "classique".
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par FluffyHamster . Évalué à 3.
Je m'auto-réponds par ce que j'ai dit une connerie, Reno avait bien raison, il y a enfaite un CPU dans le videocore (qui n'est pas le GPU) et qui sert (juste ?) à exécuter le "vrai" driver.
Donc le "faux" driver (user space et kernel) publié par broadcom ne fait que forwarder les appels opengl et autres au CPU du videocore par l'intermédiaire du CPU principal. Le CPU du videocore commande à son tour le GPU.
Enfaite toute les infos sont la dedans, mais il faut faire le tri : http://www.raspberrypi.org/archives/2221
Les specs du soc BCM2835 ne sont même pas accessible, c'est triste…
[^] # Re: Et les sources du gros firmware qui gère le GPU?
Posté par xcomcmdr . Évalué à 1.
C'est bien tordu comme bidule.
Du coup, je me demande si le gain d'économie d'énérgie (plutôt que de passer par le CPU centrale) est bien réel..
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Source du noyau
Posté par alpha_one_x86 (site web personnel) . Évalué à 8.
Ce qui m'intéresse c'est les sources du noyau libre, et l'intégration dans la branche principale. Histoire d'avoir un noyau à jour.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Pétard mouillé
Posté par Aissen . Évalué à 10. Dernière modification le 24 octobre 2012 à 23:21.
Comme dit sur les commentaires du blog par Luc Verhaegen, sur LWN par Swetland/Glisse/Clark/Bergmann, ou sur son blog par Dave Airlie, ceci est un pétard mouillé. Ce n’est pas un driver OpenGL complet car celui-ci se trouve sur autre cœur, et le code libéré n’a accès qu’à une interface RPC pour appeler le code original.
La grosse différence avec un firmware "classique" de GPU, c’est qu’ici on ne peut par exemple pas ajouter de nouvelles extensions GLES ou améliorer le compilateur de shaders. On ne peut pas faire grand chose en fait tant l’interface est haut niveau.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 3.
Faudrait mettre à jour la dépêche, la fondation rpi a un peu annoncé n'importe quoi au final…
[^] # Re: Pétard mouillé
Posté par gpe . Évalué à 4.
Oui et non car au final tout ce qui tourne sur le cœur Linux est bien libre, non ?
[^] # Re: Pétard mouillé
Posté par Aissen . Évalué à 5.
Pour certains oui. Ce n’est en tous cas pas le cas de tous les développeurs impliqués dans la pile graphique libre.
Ce GPU est particulier, et différent de tous les autres dans la mesure où sont "firmware" tourne sur un processeur qui a plus de charge que ce qui se fait habituellement. Habituellement, le firmware s’occupe de taches annexes comme la gestion de l’énergie, ou décharger le CPU de quelques opérations lourdes. Ici, l’intégralité du driver est sur un autre processeur, dans ce qu’on appelle "firmware". Firmware qui contient l’implémentation OpenGLES ou encore le compilateur de shaders (!). Ce dernier est l’un des composant les plus secrets des GPU.
Et il m’est d’avis que ce n’est pas dû au hasard. Broadcom est un des derniers entrants dans le domaine des SoC, aussi ça ne m’étonnerai pas qu’au moment du design du GPU, ils aient fait ce choix en pensant aux drivers "libres" sous Linux. Ou alors ils voulaient vraiment que le CPU fasse un minimum de choses pour minimiser la consommation, mais j’en doute fort.
Donc sans accès aux basses couches du GPU, ce driver est fort peu utile vu qu’on ne peut écrire de driver Mesa. Ça veut dire qu’on est tributaire du bon vouloir de Broadcom pour corriger les bugs de l’implémentation, améliorer les performances, rajouter des extensions OpenGL(ES), ou s’assurer que la mémoire mappée par le GPU ne vas écraser notre bon vieux sudo (raisons de sécurité).
[^] # Re: Pétard mouillé
Posté par xcomcmdr . Évalué à 5.
Vu comment le CPU est sous-dimensionné et que le Rasberry Pi est censé consommer peu (c'était quoi déjà le buzz dessus ? Un ordi qui consomme que 2W ?), l'explication reposant sur l'économie d'énergie me semble plus que plausible.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pétard mouillé
Posté par rictus (site web personnel) . Évalué à 9.
Je comprends les arguments et le fait que l'annonce de rpi fait buzz commercial.
Mais je trouve un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
Oui, il reste un "firmware" fermé et visiblement incontournable, mais c'est déjà le cas pour beaucoup de matériels.
Je me souviens de l'époque des modems USB Fast800 ADSL : Baud123 avait fait un bon lobbing sur Sagem pour obtenir les source et libérer la partie driver du modem. Ca m'avait changé la vie : certes le firmware chargé sur le modem était toujours fermé et l'API en plus opaque (Baud123 a pesté pas mal dessus), mais sur la partie driver, cela avait permis de corriger beaucoup de choses (notamment des fuites mémoire) et d'obtenir au final un périphérique très utilisable (même très stable chez moi) sous linux… Et le kernel linux restait "propre".
Pour une carte graphique d'un PC, si je prends l'exemple de mon chipset avec une radeon HD4200, certes il y a un pilote complétement libre (encore que, il y a tout de même un bout de firmware, je ne connais pas sa licence), avec la possibilité pour qui voudrait d'améliorer ce qu'il souhaite… mais au final, les performances de ce pilote libre sont toujours très loin derrière celles du pilote proprio. Il faudrait que cela soit ce dernier qui soit libéré pour être 100% gagnant pour l'utilisateur finale. Donc je ne considère pas que amd fait mieux que broadcom par exemple.
Je ne lancerais pas de troll avec NVIDIA.
Le raspberry me semble donc être un des matériels les plus libres qui existent : je ne vous dis pas d'en être un fanatique extrémiste incapable d'aucun esprit critique. Mais avoir constamment l'esprit chagrin et dénigrer les bonnes volontés qui font avancer le shmilblik, ça n'est pas top non plus.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 25 octobre 2012 à 11:32.
Tant qu'à faire, au lieu d'écrire que Broadcom avait libéré le pilote, ils auraient pu écrire qu'ils libéraient toute l'informatique.
Reconnais que ça aurait été un peu rabat-joie de ne pas vouloir admettre que c'est tout de même une avancée d'avoir un morceau propriétaire en moins.
[^] # Re: Pétard mouillé
Posté par rakoo (site web personnel) . Évalué à 3.
Je te conseille d'aller voir le Allwinner A10, qui propulse pas mal d'objets, dont la cle MK802 : Ce A10 m'a tout l'air d’être un bon candidat pour aller loin dans l'open source (C'est la volonté du fabricant, si j'ai bien compris)
Ya meme une carte qui a un nom sympa.
[^] # Re: Pétard mouillé
Posté par rictus (site web personnel) . Évalué à 1.
Cette plate-forme est attrayante car sensiblement plus puissante que le Raspberry, mais aussi plus cher (tout en restant, je te l'accorde, très abordable).
Mais en ce qui concerne l'open source, de ce que j'en lis, je crois qu'elle a encore pas mal à prouver.
(Aucun support du GPU Mali pour Linux, semble plus orientée Android, sans pour autant être officiellement supporté par CyanogenMod…).
Aller, je ne vais pas voir le verre à moitié vide, mais pour l'instant : à suivre !
[^] # Re: Pétard mouillé
Posté par fusible . Évalué à 2.
Ce n'est pas tout à fait exact. Il y a des drivers officiels ainsi qu'un projet de pilote libre. Enfin, actuellement je suis incapable d'utiliser l'un ou l'autre malheureusement.
[^] # Re: Pétard mouillé
Posté par NumOpen . Évalué à 2.
Il y a aussi http://rascalmicro.com/
[^] # Re: Pétard mouillé
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 27 octobre 2012 à 02:53.
c'est ce genre d'attitude qui est déprimante :/
le souci principal était que le pilote était hors-kernel et le firmware non distribuable (en plus).
Nous avons finalement résolu le souci de l'inclusion du module (pilote) au kernel une fois réécrit par Damien Bergamini (un dév' BSD) puis repris par Matthieu (oui, 2 t…) pour avoir l'opiniâtreté de l'inclure au noyau, avec l'aval de GKH.
Je n'ai géré que deux choses entretemps :
Pour autant, qu'ai-je obtenu ?
Pour autant, j'ai une satisfaction, cela date de 2006 mais Red Hat est revenu vers nous ensuite (ou moi en tout cas) pour pérenniser la situation au travers des firmwares non libres hébergés sur kernel.org (heureusement que debian avait promu kernel-firmware comme module permettant de charger du non-libre, tant qu'il est au bon emplacement, pour un module permettant d'accéder au net et demandant un firmware dispo par internet vu que non distribué, le problème de la poule et de l'œuf m'est souvent apparu… bah suffit d'une clé USB :p ou prendre le risque de le mettre à dispo, forcément c'est dur d'assumer la position des fabricants et des distributeurs que ce n'est pas que de leur faute, si un peu quand même).
Parce que bon concrètement :
depuis les modems usb sont morts et heureusement, remplacés par de l'ethernet, je ne sais pas si nous y avons gagné avec les box (considérées comme faisant partie du réseau interne par Free, moui, je ne suis pas convaincu, elle est tout de même chez moi, comment s'applique HADOPI ? à raison, je considère Free^WIlliad responsable par défaut dans ce cas… pour non fourniture des moyens me permettant de sécuriser ma connexion, ah bah oui, autrement c'est la FSF-France qui gagne son procès de non distribution du code de la Freebox dans les 3 ans impartis, à eux de choisir…). Je vous laisse relire 4 ou 5 fois les lignes précédentes (le niveau d'information est un peu dense, je puis répondre aux questions précises, ayant tout l'historique de l'époque même si je n'ai pas tout le contexte).
Bref, oui, j'aime promouvoir le openhardware mais pour autant ai-je envie de le supporter au vu de l'hypocrisie criante du monde android même cyanogenmod ? Ils ne respectent pas le libre, en font fi (nous avons 3M d'utilisateurs pourquoi cela serait un problème de distribuer du non-libre ?). Si personne ne s'en inquiète, bin ce n'est pas mon problème, moi non plus je n'ai pas envie de m'impliquer (je pourrais pourtant faire deux-trois choses, mais là je n'ai pas envie, ce n'est pas mon combat si tout le monde s'en fout et que ça n'intéresse personne, pour autant ça me semble dommageable et ça me désespère, mais je ne ferai rien seul et vu que je ne vois pas les choses changer… malgré l'espoir que m'avait donné Open Silicium, qui pourrait renaître àmha).
bref
Quand je te vois écrire
c'est une négation de la démarche que j'ai pu avoir, à quoi servait elle ? à qui aurait-elle pu servir ?
ok, à personne, j'ai perdu mon temps, dommage tant pour toi, que pour moi et ça ça fait chier. Surtout pour toi, moi j'y ai appris 2-3 choses au passage (mais c'est justement cette partie que j'aurai du mal à faire comprendre dans la durée et qui m'embête le plus finalement :/ Je sais par les échanges IRL que j'ai que c'est intéressant, mais qui est en mesure de le comprendre effectivement dans d'autres domaines ?).
[^] # Re: Pétard mouillé
Posté par gnuzer (site web personnel) . Évalué à 3.
Le plus simple pour savoir ça, c'est d'installer une distro blob-free, et de regarder si tout fonctionne aussi bien. Moi j'installe debian, et je regarde la différence avant et après avoir installé
firmware-linux-nonfree.Pour info, la quasi-totalité (et peut-être même la totalité ?) des firmwares AMD sont non-libres. Il suffit d'un
aptitude show firmware-linux-nonfree | grep radeonpour s'en rendre compte (ou de regarder sur git.kernel.org).Mais visiblement, ce ne sont que les cartes graphiques qui sont listées. J'ai vu des IGP qui nécessitaient un firmware proprio pour fonctionner (c'est le cas du 740G/Radeon 2100, je suppose que c'est pareil pour tous ceux pour lesquels il est écrit "Public documentation is not available yet" ici.), d'autres qui pouvaient fonctionner sans firmware (c'est le cas du 880G/Radeon HD 4250).
Et d'après ce que je lis, des Radeon HD 4200 il y en a deux. Un qui est basé sur 785G et un qui est basé sur 785E. Notons que le 785G a le même nom de code que 880G (RS880), est-ce qu'on peut en déduire quelque chose concernant le firmware ou ça n'a aucun rapport ?
En passant si quelqu'un connaît un site listant tous les GPU AMD connus, en précisant si ceux-ci nécessitent un firmware pour fonctionner, si le firmware est proprio ou non, et si les specs sont dispos ou non, qu'il n'hésite pas à partager l'info.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 28 octobre 2012 à 16:08.
La doc est souvent ancienne sur le wiki freedesktop/gallium
Ici celle fournie par AMD http://www.x.org/docs/AMD/ (rien depuis le 11-Jun-2010)
Et puis ils ont tendance à cacher ce qui est pas supporté
par ex ici tu remarqueras que les radeon gèrent très bien la fréquence et le ventilo, et il est bien connu qu'elles ne chauffent pas avec le pilote libre http://www.x.org/wiki/RadeonFeature (Power Saving)
Là les softs qui marchent ou pas http://www.x.org/wiki/RadeonProgram
Aucune mention des firmwares vu que pour les devs du pilote libre radeon ce n'est pas un pb (ça a été dit plusieurs fois en commentaire dans le forum de phoronix)
Pitet que tu trouveras des infos ici http://en.gentoo-wiki.com/wiki/Radeon http://wiki.debian.org/AtiHowTo http://www.x.org/wiki/radeonBuildHowTo (All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files to work properly with acceleration)
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 0.
Sinon j'ai regardé le paquet firmware-linux-nonfree fourni par Debian :
/lib/firmware/r128
/lib/firmware/r128/r128_cce.bin
/lib/firmware/radeon
/lib/firmware/radeon/BARTS_mc.bin
/lib/firmware/radeon/BARTS_me.bin
/lib/firmware/radeon/BARTS_pfp.bin
/lib/firmware/radeon/BTC_rlc.bin
/lib/firmware/radeon/CAICOS_mc.bin
/lib/firmware/radeon/CAICOS_me.bin
/lib/firmware/radeon/CAICOS_pfp.bin
/lib/firmware/radeon/CAYMAN_mc.bin
/lib/firmware/radeon/CAYMAN_me.bin
/lib/firmware/radeon/CAYMAN_pfp.bin
/lib/firmware/radeon/CAYMAN_rlc.bin
/lib/firmware/radeon/CEDAR_me.bin
/lib/firmware/radeon/CEDAR_pfp.bin
/lib/firmware/radeon/CEDAR_rlc.bin
/lib/firmware/radeon/CYPRESS_me.bin
/lib/firmware/radeon/CYPRESS_pfp.bin
/lib/firmware/radeon/CYPRESS_rlc.bin
/lib/firmware/radeon/JUNIPER_me.bin
/lib/firmware/radeon/JUNIPER_pfp.bin
/lib/firmware/radeon/JUNIPER_rlc.bin
/lib/firmware/radeon/PALM_me.bin
/lib/firmware/radeon/PALM_pfp.bin
/lib/firmware/radeon/R100_cp.bin
/lib/firmware/radeon/R200_cp.bin
/lib/firmware/radeon/R300_cp.bin
/lib/firmware/radeon/R420_cp.bin
/lib/firmware/radeon/R520_cp.bin
/lib/firmware/radeon/R600_me.bin
/lib/firmware/radeon/R600_pfp.bin
/lib/firmware/radeon/R600_rlc.bin
/lib/firmware/radeon/R700_rlc.bin
/lib/firmware/radeon/REDWOOD_me.bin
/lib/firmware/radeon/REDWOOD_pfp.bin
/lib/firmware/radeon/REDWOOD_rlc.bin
/lib/firmware/radeon/RS600_cp.bin
/lib/firmware/radeon/RS690_cp.bin
/lib/firmware/radeon/RS780_me.bin
/lib/firmware/radeon/RS780_pfp.bin
/lib/firmware/radeon/RV610_me.bin
/lib/firmware/radeon/RV610_pfp.bin
/lib/firmware/radeon/RV620_me.bin
/lib/firmware/radeon/RV620_pfp.bin
/lib/firmware/radeon/RV630_me.bin
/lib/firmware/radeon/RV630_pfp.bin
/lib/firmware/radeon/RV635_me.bin
/lib/firmware/radeon/RV635_pfp.bin
/lib/firmware/radeon/RV670_me.bin
/lib/firmware/radeon/RV670_pfp.bin
/lib/firmware/radeon/RV710_me.bin
/lib/firmware/radeon/RV710_pfp.bin
/lib/firmware/radeon/RV730_me.bin
/lib/firmware/radeon/RV730_pfp.bin
/lib/firmware/radeon/RV770_me.bin
/lib/firmware/radeon/RV770_pfp.bin
/lib/firmware/radeon/SUMO2_me.bin
/lib/firmware/radeon/SUMO2_pfp.bin
/lib/firmware/radeon/SUMO_me.bin
/lib/firmware/radeon/SUMO_pfp.bin
/lib/firmware/radeon/SUMO_rlc.bin
/lib/firmware/radeon/TURKS_mc.bin
/lib/firmware/radeon/TURKS_me.bin
/lib/firmware/radeon/TURKS_pfp.bin
[^] # Re: Pétard mouillé
Posté par patrick_g (site web personnel) . Évalué à 5.
Fait.
[^] # Re: Pétard mouillé
Posté par patrick_g (site web personnel) . Évalué à 10.
Oh my god, le fou rire que j'ai eu en lisant l'article de Phoronix ! J'en ai recraché mon ricoré sur l'écran du portable.
Franchement il n'a pas honte Michael Larabel. Il copie/colle un paragraphe du post de Dave Airlie mais il prend bien soin de s'arrêter à un endroit stratégique.
Version originale (je graisse le passage):
Version copiée/collée sur Phoronix :
[^] # Re: Pétard mouillé
Posté par ahuillet (site web personnel) . Évalué à 6.
Il y a un certain nombre de développeurs dans la pile X.org qui détestent Phoronix et le font savoir. Dave Airlie fait partie d'eux. C'est loin d'être la personne la plus objective à propos de Phoronix.
Phoronix est un des seuls sites "grand public" à communiquer sur ce qui se passe dans le monde de X, parfois avec des approximations et souvent avec des titres racoleurs, mais je considère que c'est plutôt un bien (et d'autres développeurs de la pile sont d'accord, ils sont juste moins bruyants).
Attention à ne pas taper sur Phoronix bêtement.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 3.
Moi je suis assidûment Phoronix, le site n'a pas vraiment d'équivalent pour savoir ce qui se passe en cuisine
[^] # Re: Pétard mouillé
Posté par patrick_g (site web personnel) . Évalué à 9.
Je lis LWN et je suis abonné aux posts d'un paquet de devs Linux dans Google+.
Chaque fois que j'ai vu Phoronix mentionné c'était pour critiquer la qualité des articles. Je n'ai jamais vu une louange de la part d'un dev Linux.
Si on ajoute :
- Le saucissonage démentiel des articles (pour avoir plus de clics)
- L'ajout effréné de liens internes au détriment des liens externes pertinents (toujours pour avoir plus de clics)
- La quantité de pubs invasives
- Les benchmarks absurdes qui ne mesurent rien
- L'embargo sur certains bugs "afin de maximiser les profits"
Je crois qu'on peut dire que Phoronix est un site déplorable.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 2.
Je n'ai pas compris ?
[^] # Re: Pétard mouillé
Posté par patrick_g (site web personnel) . Évalué à 6. Dernière modification le 25 octobre 2012 à 14:58.
A un moment il y a eu une régression du noyau sur la consommation d'énergie. Une nouvelle version consommait plus de courant que les précédentes.
Phoronix a publié des tonnes d'articles en exploitant l'affaire jusqu'au trognon. Il annonçait qu'il allait bissecter le problème. Puis il annonçait que c'était en cours. Puis un autre article pour dire que le problème était en bonne voie de compréhension grâce à son super produit Phoronix Bench suite. Etc etc.
Et enfin un article avec la phrase suivante : "I think I may have tracked down and will announce then in a couple of days. So, yes, I'll just put out the findings when it's to my maximum ad-revenue advantage."
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 1.
J'avais suivi ça vaguement, d'après ce qu'il avait dit il avait à débusquer le lièvre ? Auquel cas il peut s'en vanter.
Je suis pas sûr de comprendre la phrase anglaise
[^] # Re: Pétard mouillé
Posté par patrick_g (site web personnel) . Évalué à 5.
Il dit qu'il a trouvé le commit à l'origine de la régression mais qu'il ne va rien dire avant quelques jours parce que ce n'est pas le moment optimal du point de vue de ses revenus publicitaires.
Et à chaque fois que je relis sa phrase j'ai envie de sortir ma batte de base-ball et de lui arranger le museau :)
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 2.
ah oui, en effet, c'est un peu chien !
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 2.
Certains commentateurs y voient de l'ironie http://phoronix.com/forums/showthread.php?55818-The-Linux-Kernel-Power-Issues-Continues-To-Bite-Users#post213861
[^] # Re: Pétard mouillé
Posté par david.g . Évalué à 1.
Je suis d'accord avec ton constat, mais sans suivre la LWN, existe t'il une autre alternative plus "fiable" ?
ArsTechnica est tombé de le panneau les deux pieds en avant.
H-Online attire le lecteur avec un titre racoleur, ensuite l'article est de meilleur qualité et nous parle du firmware "closed source", mais bon.
Je suis toujours à la recherche d'un site dans la veine de Phoronix, mais sans les saucisses, existe-t'il ?
[^] # Re: Pétard mouillé
Posté par ahuillet (site web personnel) . Évalué à 2.
Tu as tort. C'est le seul site à faire des benchmarks, et certains sont pertinents. Pas tous, mais au moins ils ont le mérite d'exister.
De plus, tu vois effectivement certains développeurs (pas les moins connus, et précisément parce qu'ils ont une grande gueule) se plaindre de Phoronix. Ce n'est pas le cas de tous. Aujourd'hui si on a des enregistrements de à peu près 100% des conférences relatives à X.org, c'est grâce à Phoronix, nonobstant la qualité des enregistrements ils ont le mérite d'exister.
C'est un peu facile de taper sur Phoronix, surtout qu'ils rendent des services que d'autres ne rendent pas. Ce sur quoi les gens comme Airlie tapent, c'est le simple fait de communiquer et de vulgariser. (Tu remarqueras qu'Airlie déteste le monde entier à part son propre employeur.)
Pour avoir porté à bouts de bras le "TiNDC" (nouvelles du développement sur Nouveau) pendant un long moment, je peux te dire que la communication n'est pas dans la culture des développeurs de X. Toi plus que d'autres devrait comprendre que c'est dommage.
[^] # Re: Pétard mouillé
Posté par reno . Évalué à 3.
Déplorable tu exagères..
Tout ce que tu dis est vrai mais il a quand même parfois des infos que d'autres non pas (par exemple des liens a des blogs que je ne connaissais).
Et parfois dans le forum il y a des développeurs qui interviennent (ça en fait un des forums les plus bizarre que je connaisse: rempli de trolleur qui n'y connaissent rien et critiquent tout mais avec de temps en temps des développeurs qui interviennent!).
Il y a plein de site avec des bizarrerie, des biais, il faut le savoir et filtrer, mais de la a déplorer qu'ils existent, non.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 2.
En tout cas ils ont leur job en l'espèce :
Information complète, donc.
[^] # Re: Pétard mouillé
Posté par antistress (site web personnel) . Évalué à 3.
Tu peux même reprendre l'affirmation de Dave Airlie : ça ne permet pas l'écriture d'un pilote Mesa/Gallium.
(contrairement à ce qui est écrit dans la dépêche)
# UTF-8
Posté par Spack . Évalué à 4.
Bien joué le petit caractère UTF-8 (✓) dans le lien de la recherche. Je n'avais encore jamais remarqué…
# Ils feraient mieux de libérer les commandes ...
Posté par Kwiknclean . Évalué à 1.
car 3 mois que j'ai reçu le mail de confirmation comme quoi ma commande serait traitée et je n'ai toujours pas reçu le produit … sympa.
Quelqu'un est-il dans le même cas ?
[^] # Re: Ils feraient mieux de libérer les commandes ...
Posté par Shuba . Évalué à 4.
Ca dépend du fournisseur chez qui tu as commandé il semblerait, chez Farnell ça va assez vite, mais chez RS Components c'est beaucoup plus lent (peut-être la faute aux accessoires qu'ils vendent avec?)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.