Après le rachat de Splitted-Desktop Systems par ITRenew, l’été a été plus que studieux, et il s’est déroulé entre le pays de l’oncle Sam et notre bon vieux continent (à ce propos si vous voulez un truc, évitez la Californie en été, c’est bourré de geeks auxquels il faut ajouter les touristes et, là, ça devient n’importe quoi sur à peu près tous les sujets).
La rentrée c’est la semaine prochaine et il est temps de reprendre un peu le travail, tout en mêlant le plaisir. Cette rentrée s’annonce chargée pour ceux qui aiment l’Open Hardware et GNU/Linux. Plusieurs événements à venir, qui tiennent à cœur à votre serviteur, sont à découvrir en deuxième partie de dépêche.
On commence par quelque chose d’assez confidentiel à Erlangen (joli bourg à côté de Nuremberg) le 12 septembre (c’est bientôt), avec l’Open Source Firmware Conference, organisée par 9Elements, un des cofondateurs du projet LinuxBoot et membre du Technical Steering Committee (dont je fais partie). Pour plus d’info, c’est là : osfc.io. Les thématiques sont assez techniques et l’on y retrouvera le gratin du développement de micrologiciels libres, ainsi que des ingénieurs travaillant chez Google, Facebook et autres hyperscalers qui contribuent fortement à l’essor de LinuxBoot (allez Octave, les ingénieurs d’OVH sont les bienvenus).
Pour ceux qui ont du mal avec l’anglais, j’y donnerai deux « talks » avec un accent français bien prononcé. Un dont le titre est révélateur, « scotch-tape and flashrom », ou la dure vie d’un ingénieur BIOS. On racontera avec Arun Koshy de TCSL research les aléas, nous dirons ce que nous avons découvert avec chipsec. Le second « talk », « LinuxBoot CI », sera sur l’automatisation des tests des micrologiciels et l’apport de LinuxBoot et OpenBMC sur ces sujets.
Autre conférence, autre rôle de speaker. Embedded recipes, organisé par Hupstream à Paris. J’y donnerai un « talk » sur les modifications nécessaires au noyau Linux pour faire fonctionner LinuxBoot (avec un petit espoir de voir certaines de nos propositions reprises en amont). J’y serai co‐speaker avec Trammell Hudson de 2sigma, probablement un des meilleurs hackers que j’ai croisé ces dernières années.
Et pour finir en feu d’artifice, (OK, je ne suis peut‐être pas totalement intègre), l’OCP summit d’Amsterdam, du 1er au 2 octobre 2018. Pour ceux qui ne connaîtraient pas encore OCP, c’est un projet fondé par Facebook en 2011 qui poursuit pour objectif de dynamiser l’innovation dans les centres de données (datacenters) au travers de projets ouverts, sur lesquels vous pouvez contribuer. Il n’y pas que du matériel, beaucoup de logiciels, d’architecture, etc. (en clair, pas d’excuses pour ne pas venir).
La plupart des grands groupes américains seront représentés (OK, on dirait comme ça que j’encense les Étas‐Unis ; mais, en même temps, même si Octave semble vouloir s’intéresser au sujet, je n’ai pas encore totalement réussi à décrypter dans son tweet ce qui l’empêchait de basculer en Open Hardware ;)).
On y sera avec un stand, pleins de surprises et de nouvelles technologies (déjà publiques, hein Octave ; ce qui compte dans la propriété intellectuelle, c’est l’antériorité). Aaron Sullivan, directeur engineering hardware de Facebook, animera plusieurs débats avec des utilisateurs européens d’équipements Open Compute et de nombreux engineering workshops se tiendront.
Cela sera aussi l’occasion de découvrir la dynamique autour de ce marché et de venir glaner quelques idées sur les stands des différents sponsors. Plus que jamais, l’union fait la force. Et si vous êtes informaticiens, cela sera probablement le bon moment pour le constater.
L’événement est payant, mais pour ceux qui voudraient y venir et qui ont un petit budget, n’hésitez pas à me contacter (mon Twitter vejmarie) ; j’essaierai de vous trouver une solution.
Bonne rentrée à tous !
Aller plus loin
- Journal à l’origine de la dépêche (384 clics)
# RISC-V
Posté par Nico7as . Évalué à 2.
Très intéressant tout ça, comme d’habitude.
Dans l’Open Hardware, RISC-V semble être prometteur. Est-ce vous travaillez déjà dessus, ou est-ce pour plus tard?
Je suis noob en hardware, mais pourrait-ton imaginer sous peu une puce RISC-V équivalente à celles des puces T1 et T2 des Mac, pour dzs serveurs ou des ordinateurs personnels?
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 9.
Non, ou alors "sous peu" c'est dans minimum cinq ans.
Concurrencer les microcontroleurs (STM, ARM, Microchip, etc.) avec des puces abordables est déjà un palier à franchir. Ensuite le marché du SoC est dominé par ARM Holdings qui lui-même peine à monter en puissance pour du serveur ou de la station de travail.
Les cartes Hifive ne sont qu'à peine sorties, il faut laisser le temps aux autres d'arriver, comme LowRISC.
Et pour un ordinateur grand public il y a le problème de l'affichage : On a toujours pas de GPU et de VPU open-hardware en ASIC ou à intégrer dans un SoC.
Enfin, RISC-V est relativement jeune et continue de se construire. Ce n'est pas gênant pour un controleur ou un cœur dans du matériel fermé (genre un HDD, une carte graphique, une console), ça l'est davantage pour un CPU ou un SoC, même propriétaire, dans un appareil dont le développement logiciel est ouvert.
[^] # Re: RISC-V
Posté par tao popus . Évalué à 2.
https://www.cnx-software.com/2018/09/04/licheetang-anlogic-eg4s20-fpga-board-targets-risc-v-development/
Après c'est sur que c'est dix fois plus cher que les clone Arduino à base de STM32 (32 bits beaucoup plus puissant que l'Atmel officiel) à 1~2 € pièce. Il existe aussi pas mal de produit ASIC basé sur RISC-V avec des prix plus ou moins élevé. On voit que les offres se multiplient et de plus en plus rapidement.
Bof, coté station de travail ça tourne carrément bien sur des ChromeBook et ordi monocartes depuis quelques années déjà, la Lunixifcation pure (GNU/Linux, pas Google/Linux) est plus longue, en raison du besoin de pilotes 100% libres, mais les derniers pilotes GPU (Merci Panfrost) et VPU (Merci freeElectronMM Bootlin + BayLibre) sont en train de s'ouvrir.
Même sans ça, ce genre de proc sur des cartes minuscules à 20~50 € (RK3288 et supérieur, Allwinner A64, etc…, oublier les RaspbPi, les proc Broadcomm sont super mal foutus (le boot sys dépend du boot GPU, et plein d'autres conflits matériel débiles) sont déjà plus confortables et infiniment plus rapide que des Core i3 ou certains i5 sur 70% des tâches, sans les nuisance du ventilo et de la conso. En fait toutes les tâches du bureautique, de surf, de dessin, de traitement photo, de son, etc… qui ne demandent pas de vidéo ou de 3D. Même en 3D, c'est assez amusant, mais blender 2.7x tourne assez bien (5~10pfs, mais pas de lag, sur les procs 32 bits) pour des scènes basique en pur logiciel (merci LLVMpipe), par contre le 2.8 (version git), c'est pas la peine).
Pour le côté desktop/laptop toujours, il faut oublier les jeux/simulateur 3d par contre, qui ne tournerons que quand on pourra passer par Vulkan (à priori que sur les modèles qui ont moins de 3 ans) ou si ils sont compatible OpenGL ES (quand les pilotes libres seront plus mures.
Côté serveur, ça fait un plusieurs années que plusieurs prestataires proposent de l'ARM (comme Free par exemple), mais c'est vrai que pour les serveurs les plus puissants, il faut encore attendre un peu.
[^] # Re: RISC-V
Posté par Anonyme . Évalué à 3. Dernière modification le 06 septembre 2018 à 05:36.
Le FPGA Anlogic est libre aussi ? Je veux dire au moins avec une interface de programmation opensource façon Lattice ? Tout ce qu'il y a c'est un datasheet et un site en chinois, tout comme le site et le github de LicheeTang.
Pour du mini FPGA c'est correct, c'est le prix de l'Upduino avec un ICE40. Mais pour un microcontroleur ça reste cher, surtout que le design du E200 est libre. On est encore loin de l'ASIC au même prix qu'un STM32.
Par contre Atmel ne fait pas que du AVR 8 bit, ils ont aussi des MC à base de Cortex-m à 32bit.
Perso j'en vois pas beaucoup (trois, en incluant les deux Freedom et GAP-8). Si tu en as d'autres je suis preneur.
-
c'est pas ce que j'appelle des stations de travail, ça se sont des netbooks, des lecteurs multimédia ou des postes légers. Je parle plutôt de performances de laptops de milieu de gamme ou de tours d'entrée de gamme avec des processeurs qui ont du cache, de la mémoire rapide et un bon nombre de FPU.
C'est surtout que les fabricants ne supportent plus leur matériel après deux ou trois ans et que les linuxiens aiment bien avoir un système relativement à jour pour plein de raisons. Autant avec un PC c'est pas trop gênant (hormis pour quelques firmwares), autant avec du ARM tu te retrouves souvent bloqué dans une vieille version de noyau, particulièrement quand tu veux un pilote GPU.
Le problème est le même sous Android.
Comme tu le dis : « sont en train de s'ouvrir »
Lima et Panfrost c'est pas pour tout de suite et c'est seulement pour les GPU Mali. Même chose pour le pilote VPU pour Amlogic. Cedrus, lui, était déjà bien avancé niveau rétro-ingénierie du blob d'Allwinner et beaucoup de boulot a été fait ces derniers mois mais il y en a encore pas mal à faire avant d'avoir quelque chose de vraiment fonctionnel (surtout pour A64, H5 et H6).
un quadcore Cortex A7 ou A53 (basse consommation, faible cache et in-order) "plus rapides que des i3" j'y crois pas du tout alors y ajouter "infiniment" me parait ridicule. Même un appareil en Celeron N3000 a davantage de puissance et de rapidité qu'un SoC ARM de cette gamme : Il faut taper du côté d'un Tegra X pour avoir un équivalent (petit comparatif c'est du bench synthétique mais ça donne une petite idée des différences en cas de charges) et là c'est plus du tout le même budget.
Je crois qu'on va continuer encore un bon moment à cross-compiler pour du arm depuis du x86.
Et les ventilos ça commence à venir sur les SoC un peu costauds : on a rien sans rien, l'effet Joule fait son office peu importe l'architecture. C'est pas anodin que la carte Sifive Freedom Unleached possède des trous de fixation de radiateur autour du SoC ou qu'il est recommandé d'en ajouter un sur les SBC utilisant un Allwinner H5. La Thinkerboard d'Asus se met en throttle même avec son radiateur si trop de charge CPU.
Moui, alors quand tu utilises plus de 4 Go de RAM (chose que les gens qui bossent en multitâche intensif font régulièrement) tu te retrouves à swapper. zram peut sauver les meubles mais jusqu'à un certain point. Pour la bureautique et le surf c'est déjà limite selon les usages, pour le dessin, la photo et le son c'est vite rempli surtout si tu utilises des logiciels, des formats et des projets lourds. C'est dans ce sens que je parlais de station de travail : on a pas besoin de la même machine quand on recadre un jpeg que quand on travaille des séries de photos en raw ou de documents d'une image matricielle format A3 en 4800ppp comprenant plusieurs dizaines de calques.
Et encore je prends 4 Go de RAM mais sur bon nombre de SBC et de laptop ARM c'est que la moitié (jamais vu de A64 avec plus de 2 Go de RAM)
Attendre beaucoup même, vu les rares serveurs ARM existants : les Centriq et Thunder c'est pour du traitement rapide à haute parallèlisation du genre hébergeur ou Web avec un paquet de machines virtuelles. C'est spécifique à un certain type d'usage et dès que t'y net un peu de tâches plus intensives en calcul ou en cache leur performance chute.
# Octave ?
Posté par Victor . Évalué à 5.
Quelqu'un peut m'expliquer les petites piques à OVH dans l'article ?
[^] # Re: Octave ?
Posté par Pinaraf . Évalué à 10. Dernière modification le 01 septembre 2018 à 19:31.
Alors je ne connais pas la relation entre vejmarie et OVH/Octave, mais ayant travaillé un certain temps à OVH je peux donner des pistes d'interprétation.
OVH se vante d'innover notamment sur le matériel, d'embrasser l'open source, de contribuer… Du coup des projet comme coreboot ou linuxboot, qui peuvent apporter moultes avantages pour des grands opérateurs de réseau, devraient intéresser et pousser à contribuer le «n°1 européen du cloud».
Mais à moins d'un changement radical depuis mon départ il y a 3 ans, OVH n'est qu'un intégrateur, gros certes, mais un intégrateur, donc je les vois vraiment mal contribuer à linuxboot. D'autant plus que pour ce qui est du cloud, ils sont maqués depuis longtemps avec VMWare, et le private cloud à base de VMWare étant devenu une belle vache à lait (au sens économique), à moins que VMWare se mette à certifier des machines sous linuxboot pour ESXI… c'est vraiment pas près d'arriver.
[^] # Re: Octave ?
Posté par Anonyme . Évalué à 6.
De ce que je crois me souvenir des précédents journaux de vejmarie c'est que les gros français n'étaient pas intéressés par le projet Nerf, par contre les américains ont vu le potentiel.
[^] # Re: Octave ?
Posté par vejmarie (site web personnel) . Évalué à 10.
J'aurai pu faire les memes pics sur online et autres cloud provider europeens. Nos entreprises ont enormement de mal a faire pivoter leurs modeles economiques lorsque de nouvelles revolutions industrielles arrivent. OVH et Online sont en effet de gros integrateurs qui pourraient innover plus tout en collaborant sans pour autant voir leur modele economique s'effondrer. le dernier tweet d'Octave mentionnant OCP tentait d'expliquer que les dernieres innovations d'OVH etaient super (ce que je peux croire, mais comme tout a chacun demande a voir), et qu'il aimerait pouvoir les partager avec les membres d'OpenCompute Project mais qu'il devait deposer des brevets auparavant. (on va se retrouver encore plus protectionnistes que les americains et les brevets logiciels si ca continue).
Tout ca me va bien, mais on attend encore comme on dit … Que ce soit Online ou OVH, qu'ils l'admettent ou pas, les projets Open Hardware influencent leurs choix, tout comme les projets Open Source, avec des niveaux de contributions bas … c'est ce qui a une certaine tendance a m'agacer on va dire. L'opacite des modeles d'OVH et Online ont peut-etre fait leur succes, je ne suis pas du tout convaincus qu'il fasse leur avenir (en meme temps je ne dirige pas ces entreprises), mais pas contre je reste convaincus que le partage du savoir fait parti du devoir des scientifiques en 2018 et des entrepreneurs si ont veut addresser les enjeux futurs. Aussi con que ca puisse paraitre les americains l'on compris et en font un business au passage la ou les francais sont restes dans les annees 90 a vouloir acheter toujours moins chere en innovant au minimum et scellant des partenariats avec des ODM asiatiques.
# Impatient !
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Oui, je suis impatient de voir la suite de l'excellent travail de Jean-Marie et de ses copains.
Il me tarde que l'on puisse se débarrasser des vieux BIOS poussiéreux et de l'affreux UEFI.
Comme toujours,il est plus efficace de s'attaquer aux causes qu'aux effets. C'est bien l'objet de ce travail car on s'attaque à la racine du mal plutôt qu'à ses effets.
En effet, combien de personnes ont été dissuadées d'installer Linux en double boot ou même d'installer Linux sur une machine "protégée" par un secure boot?
Il me tarde de voir sauter ce verrou qui est à mon avis l'un des principaux freins à l'adoption de Linux et des logiciels libres. Quand cela arrivera, il y a fort à parier que Microsoft proposera sa distribution Linux…
# Méthodes formelles ?
Posté par Harvesterify (site web personnel) . Évalué à 3.
Crossposting à partir du journal initial :
Hello,
Merci pour cette annonce, les talks des conférences citées ont effectivement l'air super intéressant !
Pour ma culture personnelle, sais-tu quel usage est fait des méthodes formelles, notamment dans une optique sécurité, dans les différents développement des firmwares ? Je vois bien des talks à propos de Trustzone, l'usage des IOMMU, etc, mais c'est déjà plus "haut niveau".
Je me posais notamment la question de savoir si l'usage des méthodes formelles pouvait intéresser vos utilisateurs (dans le cadre de la certification de vos firmwares pour des usages étatiques, entre autres).
Mes messages engagent qui je veux.
[^] # Re: Méthodes formelles ?
Posté par vejmarie (site web personnel) . Évalué à 4.
A ma connaissance tres peu de choses de faites, mais je serai interesse par creuser un peu ce sujet.
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4. Dernière modification le 03 septembre 2018 à 08:05.
De quelles genres de méthodes formelles vous parlez ? "formel" est utilisé pour beaucoup de chose très différent.
"La première sécurité est la liberté"
[^] # Re: Méthodes formelles ?
Posté par Harvesterify (site web personnel) . Évalué à 3.
Justement la question est ouverte sur toutes les méthodes formelles, puisque je n'ai pas de visibilité sur ce qu'il se fait actuellement dans le domaine sur ce sujet.
Ce qui m'intéresse, c'est l'usage possible/avéré des méthodes formelles pour la sécurité des architectures matérielles. Pour donner un exemple, je suis avec attention ce genre de chose : https://www.researchgate.net/publication/327027099_Implementing_a_hardware-assisted_memory_management_mechanism_for_ARM_platforms_using_the_B_method
Mais dans le cas de LinuxBoot, ça serait plutôt de savoir si il y a un intérêt quelconque et une plus-value à utiliser des méthodes formelles (lesquelles, comment ?) pour le développement ou la validation, et en particulier vis à vis d'exigences de sécurité, type celles Critères Communs.
Mes messages engagent qui je veux.
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
"La première sécurité est la liberté"
# Erlingen → Erlangen
Posté par Cyril Brulebois (site web personnel) . Évalué à 4.
Erlingen c'est plutôt du côté de München. C'est Erlangen à côté de Nürnberg (confirmé sur le site de la conférence).
Debian Consultant @ DEBAMAX
[^] # Re: Erlingen → Erlangen
Posté par vejmarie (site web personnel) . Évalué à 7. Dernière modification le 02 septembre 2018 à 20:18.
Exact un mixte de faute de frappe et de mauvaise connaissance de la geographie allemande ;), par chance mon billet d'avion m'emmene au bon endroit.
[^] # Re: Erlingen → Erlangen
Posté par Davy Defaud . Évalué à 4.
Corrigé.
[^] # Re: Erlingen → Erlangen
Posté par samydb . Évalué à 4.
Pour la géographie défaillante, tu n'es pas le seul (malheureusement)
https://www.dailymotion.com/video/x2j3zzw
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.