En fait, je parlais de ces problèmes (mon objectif est justement de me passer le plus possible de blobs non reproduisibles par des sources) : https://wiki.debian.org/RaspberryPi#line-52
Ça me plairait assez que ce SBC se libère un peu plus car ses caractéristiques techniques commencent à être intéressantes, notamment au niveau de la RAM pour en faire une plateforme auto-hébergée plus en phase avec les performances actuelles.
Par contre, sans doute un avis de néophyte sur le sujet, un GPU ça sert essentiellement à gérer la partie graphisme (de mon temps il n'y en avait pas d'ailleurs, le CPU se tapait tout). Pourquoi lui faire gérer le démarrage de la plate-forme ? On dirait un gros hack méchant pour faire tomber en marche le système.
[^] # Re: Est-ce-que c'est plus libre qu'avant ?
Posté par Médéric RIBREUX (site web personnel) . En réponse au journal une nouvelle framboise. Évalué à 6.
En fait, je parlais de ces problèmes (mon objectif est justement de me passer le plus possible de blobs non reproduisibles par des sources) :
https://wiki.debian.org/RaspberryPi#line-52
A noter que l'initiative pour faire un "bootloader" libre sur cette série de SOC Broadcom est en arrêt: https://github.com/christinaa/rpi-open-firmware/issues/37
Ça me plairait assez que ce SBC se libère un peu plus car ses caractéristiques techniques commencent à être intéressantes, notamment au niveau de la RAM pour en faire une plateforme auto-hébergée plus en phase avec les performances actuelles.
Par contre, sans doute un avis de néophyte sur le sujet, un GPU ça sert essentiellement à gérer la partie graphisme (de mon temps il n'y en avait pas d'ailleurs, le CPU se tapait tout). Pourquoi lui faire gérer le démarrage de la plate-forme ? On dirait un gros hack méchant pour faire tomber en marche le système.