Super journal ! Peu de personnes ont conscience du souci posé par le Management Engine :-/
Bon, j'ai quand même 3-4 remarques (sans grande importance, juste pour pinailler :)
Premier truc : je suis surpris par la phrase suivante dans le journal
dont le sous-projet le plus avancé semble être OpenRISC, un microprocesseur basé sur l'architecture libre RISC-V
Je pense (je peux me tromper) que OpenRISC est antérieur et n'utilise pas l'ISA RISC-V. "RISC" est un terme générique (même "ARM" signifiait "Acorn RISC Machine" !)
Tant que j'y suis, on lit aussi
MIPS Technologies appartient depuis 2013 à Imagination Technologies (qui n'est pas vraiment l'ami du logiciel libre), mais quelques compagnies continuent à produire des processeurs MIPS. La plus connue est sûrement le chinois Lemote.
Rappelons quand même que des coeurs comme MIPS24k sont utilisés dans un nombre considérables de SoCs pour routeurs chez Atheros/Mediatek/Realtek (par exemple l'AR9331, mais c'est juste un exemple)
Bon OK, on parlait d'un usage Desktop... On pourrait dans ce cas parler des SoC Ingenic, et justement comme le journal parle de EOMA68, Rhombus-Tech a justement envisagé de recourir à un processeur MIPS32 Ingenic JZ4775, qui était d'ailleurs apparemment le "meilleur" candidat d'un point de vue théorique/ouverture (là où Allwinner n'a pas spécialement bonne réputation...) mais malheureusement s'est finalement avéré irréaliste dans leur contexte (Initially, two EOMA68 Computer Cards were developed: one using an Ingenic jz4775, the other with an Allwinner A20. We planned to apply for RYF Certification on the jz4775 card because not only is there no GPU (there’s a Vector FPU similar to AltiVec), but the video processor’s source code is entirely GPL compliant, making it a seemingly perfect candidate for RYF Certification. However, upon close investigation, the only FSF-endorsed operating systems available for MIPS32 were so horribly-out-of-date that the resulting device would be pretty much unsaleable even to FSF supporters. Reluctantly we had to drop the jz4775 from immediate consideration), donc ça veut dire que "MIPS" ne signifie pas nécessairement "pas sympa avec le libre" :)
(N.B. je pense que cette réputation "pas cool avec le libre" vient surtout des GPU PowerVR et pas de la partie "MIPS", et j'avais discuté avec des personnes de Imagination Technologies il y a qq temps. J'ai retenu que des ingénieurs souhaitent faire bouger les choses en interne, mais c'est apparemment pas simple et ça prend du temps - notamment quand ils ont eux-même sous-traité / acheté du code à d'autres fournisseurs sous licence...)
Dernière chose - un peu hors-sujet : en ce qui me concerne sur le non-x86, mon premier souci est que beaucoup de fabricants de SoC et/ou OEMs se contrefichent généralement de la GPL (suffit de chercher "GPL violation" ou de demander les sources du kernel à à peu près n'importe quel OEM asiatique à base de Allwinner/Rockchip/ActionSemi/Mediatek/...), ceci alors même que ARM ne permet pas "one kernel to rule them all", et que le côté monolithique (+ l'idéologie "stable API nonsense") de Linux ne permet pas de découpler les parties dépendantes du HW du reste (pour recompiler facilement les parties génériques du kernel et combler une faille de sécurité par exemple). Bref, aujourd'hui le x86 reste encore la seule manière d'avoir une machine qui ne soit pas "jetable" au bout de 3 ans... (OK, j'exagère peut-être un peu : des fabricants de SoC comme NXP/TI s'engagent sur du support à long terme, ainsi que sur le support du device-tree, donc peut-être que j'accuse injustement ARM dans son ensemble. Mais c'est un fait que aujourd'hui tu peux booter une clé USB Linux générique sur n'importe quel PC du monde, alors qu'il faut une distro spécifique pour chaque machine ARM, réduisant sa durée de vie à celle du support)
On l'a bien vu et les contributeurs du projet Purism s'en sont mordus les doigts : dans l'état actuel des choses, il n'est pas possible de faire un ordinateur dépourvu de logiciels non-libres basé sur x86.
Purism s'y est cassé les dents, mais ce ne sont pas les seuls (et ça fait peur) : Google engineers have tried for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.
Parmi les acteurs développant des plateformes ARM haut de gamme, on trouve NXP Semiconductors, surtout connu sous son ancien nom : Freescale. Leur LS2085A NPU (Network Processing Unit) est probablement ce qui se rapproche le plus d'une station de travail moderne dans le monde ARM haut de gamme.
En dehors de Freescale, il me semble que nvidia a plutôt bien progressé en matière d'ouverture (d'après ce que je comprends, je n'ai pas été vérifier dans le détail), et ils n'utilisent évidemment pas de GPU Mali. M'enfin bon, y'a toujours plein de blobs et c'est sûrement un peu moins ouvert que NXP/Vivante, n'empêche que:
je n'ai pas connaissance d'un truc analogue au Management Engine (par contre, nvidia garde jalousement la SBK, qui permet théoriquement de débricker n'importe quelle shield-tablet avec nvflash. Mais j'imagine que rien n'empêcherait un OEM de concevoir une carte-mère à base de K1 tout en étant plus sympathique sur le bootloader/SBK)
ça permet des machines raisonnablement performantes et peu énergivores et pas chères (bref "modernes")
ça fait tourner Ubuntu 14.04 aujourd'hui (avec accélération graphique/vidéo. J'ignore si l'état de ce qui est libre vs blobs permet de recompiler et faire fonctionner facilement 16.04. En tout cas le kernel est basé sur un Device-Tree à ma connaissance, ce qui est moins merdique que beaucoup de concurrents)
# 2-3 remarques
Posté par karteum59 (site web personnel) . En réponse à la dépêche Le logiciel libre au-delà de x86. Évalué à 10. Dernière modification le 29 août 2016 à 03:32.
Super journal ! Peu de personnes ont conscience du souci posé par le Management Engine :-/
Bon, j'ai quand même 3-4 remarques (sans grande importance, juste pour pinailler :)
Premier truc : je suis surpris par la phrase suivante dans le journal
Je pense (je peux me tromper) que OpenRISC est antérieur et n'utilise pas l'ISA RISC-V. "RISC" est un terme générique (même "ARM" signifiait "Acorn RISC Machine" !)
Tant que j'y suis, on lit aussi
Rappelons quand même que des coeurs comme MIPS24k sont utilisés dans un nombre considérables de SoCs pour routeurs chez Atheros/Mediatek/Realtek (par exemple l'AR9331, mais c'est juste un exemple)
Bon OK, on parlait d'un usage Desktop... On pourrait dans ce cas parler des SoC Ingenic, et justement comme le journal parle de EOMA68, Rhombus-Tech a justement envisagé de recourir à un processeur MIPS32 Ingenic JZ4775, qui était d'ailleurs apparemment le "meilleur" candidat d'un point de vue théorique/ouverture (là où Allwinner n'a pas spécialement bonne réputation...) mais malheureusement s'est finalement avéré irréaliste dans leur contexte (Initially, two EOMA68 Computer Cards were developed: one using an Ingenic jz4775, the other with an Allwinner A20. We planned to apply for RYF Certification on the jz4775 card because not only is there no GPU (there’s a Vector FPU similar to AltiVec), but the video processor’s source code is entirely GPL compliant, making it a seemingly perfect candidate for RYF Certification. However, upon close investigation, the only FSF-endorsed operating systems available for MIPS32 were so horribly-out-of-date that the resulting device would be pretty much unsaleable even to FSF supporters. Reluctantly we had to drop the jz4775 from immediate consideration), donc ça veut dire que "MIPS" ne signifie pas nécessairement "pas sympa avec le libre" :)
(N.B. je pense que cette réputation "pas cool avec le libre" vient surtout des GPU PowerVR et pas de la partie "MIPS", et j'avais discuté avec des personnes de Imagination Technologies il y a qq temps. J'ai retenu que des ingénieurs souhaitent faire bouger les choses en interne, mais c'est apparemment pas simple et ça prend du temps - notamment quand ils ont eux-même sous-traité / acheté du code à d'autres fournisseurs sous licence...)
Dernière chose - un peu hors-sujet : en ce qui me concerne sur le non-x86, mon premier souci est que beaucoup de fabricants de SoC et/ou OEMs se contrefichent généralement de la GPL (suffit de chercher "GPL violation" ou de demander les sources du kernel à à peu près n'importe quel OEM asiatique à base de Allwinner/Rockchip/ActionSemi/Mediatek/...), ceci alors même que ARM ne permet pas "one kernel to rule them all", et que le côté monolithique (+ l'idéologie "stable API nonsense") de Linux ne permet pas de découpler les parties dépendantes du HW du reste (pour recompiler facilement les parties génériques du kernel et combler une faille de sécurité par exemple). Bref, aujourd'hui le x86 reste encore la seule manière d'avoir une machine qui ne soit pas "jetable" au bout de 3 ans... (OK, j'exagère peut-être un peu : des fabricants de SoC comme NXP/TI s'engagent sur du support à long terme, ainsi que sur le support du device-tree, donc peut-être que j'accuse injustement ARM dans son ensemble. Mais c'est un fait que aujourd'hui tu peux booter une clé USB Linux générique sur n'importe quel PC du monde, alors qu'il faut une distro spécifique pour chaque machine ARM, réduisant sa durée de vie à celle du support)
Purism s'y est cassé les dents, mais ce ne sont pas les seuls (et ça fait peur) : Google engineers have tried for many years to get source code from Intel, and to reverse engineer the blobs that Intel provides. So far, they have been unsuccessful. Google is also one of the companies that funds the coreboot project, and they hire a lot of the core developers, so it's not like they don't have vast resources at their disposal. Smaller companies have no chance.
En dehors de Freescale, il me semble que nvidia a plutôt bien progressé en matière d'ouverture (d'après ce que je comprends, je n'ai pas été vérifier dans le détail), et ils n'utilisent évidemment pas de GPU Mali. M'enfin bon, y'a toujours plein de blobs et c'est sûrement un peu moins ouvert que NXP/Vivante, n'empêche que: