En en lisant plus j'ai compris que je n'avais pas compris (justement) quelque chose, en fait il faut le comptage est en cellules logiques != LUT. La LUT (table de vérité) n'en est qu'un élément, avec les flip-flop/latch (bascule D), les Mux et l'additionneur. Les organisations de ces éléments varient visiblement grandement d'un constructeur à l'autre avec leurs avantages et inconvénients en terme d'efficacité.
Xmpp s’est ramassé parce qu’ils ont mit des années à implémenter des trucs que tout le monde avait
A bon, qu'est-ce qu'ils ont mis des années à implémenter que les autres avaient déjà? Quand xmpp est sorti, j'étais principalement sur le très vieux IRC comme la majorité des gens participant à des projets du libre, j'avoue que j'y suis retourné parce qu'il y avait plus de gens. Mais il y avait d'autres expériences intéressantes avec XMPP, comme les tableaux blancs (Inkscape, Coccinella, qui utilisaient ce protocole). La partie Inkscape n'a pas été maintenue puis abandonnée, et pareil pour Coccinella, c'est dommage. De cette époque XMPP est le seul protocole qui reste avec IRC. IRC reste l'outil principal dans le développement des plus gros projets libres, mais les serveurs XMPP de cette époque sont toujours actifs. Différents projets utilisent des plateformes plus fragmentées aujourd'hui (Telegram+Discord par exemple ou IRC+Matrix+Telegram via des ponts matrix qui existent depuis plusieurs années).
Il y a à présent Drawpile qui utilise son propre protocole pour le tableau blanc et d'autres outils qui passent par un serveur HTTP(s).
Les clients libres qui se pointent en disant en substance “notre facteur de différentiation c’est de rendre vachement plus compliqué la construction de ton réseau social grâce à la décentralisation sans offrir quoi que ce soit de plus que la concurrence” vont effectivement droit dans le mur, a plus forte raison s’ils n’ont pas une entité commerciale très forte pour les aider à percer.
Personne n'a besoin d'être le numéro tant que ça sert son intérêt. Sur ce point, Le Fédiverse, avec un point supplémentaire pour tout ce qui tourne autour d'ActivityPub fonctionne déjà pas mal. Bon, c'est vrai que par contre, ça n'agglomère presque que des gens intéressants. Il semble qu'il y ai moins les guerres des Twitter & Facebook. Il y a des petites batailles de courte durée. Chacun se bloque de son côté quand il y a un désaccord profond entre 2 groupes et les autres continuent à converser. Il n'y a pas un blocage de la « main de dieu » (du roi ?). On retrouve donc sur le Fediverse une partie du publique d'IRC. Je reste dubitatif sur l’intérêt profond de ce genre de plateforme, moitié temps réel comme un chat, moitié web, permettant la relecture, et finalement, difficile à en tirer des informations pérennes. Je vois cela plutôt comme un outil intermédiare, plus étendu que des canaux spécialisés d'IRC qui compartimentent un peu, ce qui permet un peu plus d'échanges, et permet d'agglomérer des gens. C'est une étape intermédiaire permettant de diriger vers différents projet et leurs canaux de diffusions (chat sur irc, site web du projet, forge logicielle associée) qui permettent de pérenniser les idées et projets.
Les retours de ce développeur sont vraiment intéressants je trouve. Il y a forcément le profil d'avantage hacker (dans le sens premier tu terme) de l'utilisateur Linux, mais ça serait encore plus intéressant d'aller plus loin et de connaître les profils des personnes.
Est-ce qu'elles sont plus efficace, parce que l'utilisation de Linux apprend à mieux comprendre le système, fourni plus d'aide, comme des logs plus explicites, avec un accès plus facile et mieux documenté, et l'aspect communautaire pousse à plus d'entre-aide ? D'un autre côté les utilisateurs de Windows habitués à cliquer sur des dizaine de OK à répétition sans rien lire ni comprendre, pousse au contraire à abandonner toute forme de compréhension.
Ou bien est-ce qu'il s'agît principalement de personnes travaillant dans le développement, dans l'admin, des profils à la base plus techniques ?
Si c'est le premier cas, c'est vraiment intéressant, cela voudrait dire que Linux répond à un besoin important d'éducation populaire et d'émancipation.
Suivre des processus établis, ça réduit les chances d'erreur, mais c'est comme les feuilles administrative, il manque souvent la case correspondant au cas que l'on rencontre. Heureusement, les humains sont là pour mitiger les erreurs des processus.
Les processus permettent d'éviter des oublis des humains
Les humains permettent d'éviter des oublis et cas non prévus dans les processus et d'améliorer les processus.
C'est comme les checklist dans les procédure de vol, et le pilotage automatique (avion ou voiture), c'est toujours mieux quand l'humain peut couper les automatismes quand ils se mettent à buguer avec des problèmes liés à des cas jamais rencontrés.
En avançant sur le sujet, je m'aperçoit que le microcontrôleur de la Tang est un Cortex-M et non un RISC-V. Il y a par contre bien un RISC-V sur la carte, un Bouffalo BL702 (basé sur un core RV32 de SiFive), mais il est utilisé pour le USB-série et le JTAG. Contrairement au ICE40, cette carte nécessite encore du proprio pour la conversion vers le bitstream (le code envoyé à la carte FPGA, cité dans l'article, je me demandais dans le précédent commentaire ce que c'était), mais le projet Apicula (et module python Apycula), au sein de Yosys justement, à pour but de libérer les FPGA Gowin/GW1N.
Et du coup, intéressant aussi, YoWASP un port des outils du projet Yosys en WASM, et l'utilisation de WASM en dehors du navigateur avec WASI de façon a avoir des outils portable. Je ne suis pas sûr que ce soit plus pertinent que Python. J'ai peur d'un gouffre à Mo avec les programmes qui rembarquent toutes les libs (à la JavaScript ou Rust et autre snap/appimage), plutôt que de réutiliser celles déjà installées comme on à l'habitude sous Linux. On vit sur une planète finie sur des ordis finis, avec toute leur entropie. Ça peut toujours dépanner dans certains cas (les outils de survie sur une clé usb de 256Go ou sur la carte SD tu téléphone branché en stockage de masse).
OOps, désolé et merci pour ce lien. C'est vrai qu'ils ont aussi l'infra pour le streaming. Ils ont sauvé cette année une demoparty qui avait eu la mauvaise idée de passer par Twitch et c'est faite censuré parce qu'il y avait un dessin de nu dans une des démos. Mieux vaut ne pas montrer le Louvre ou n'importe quel autre musée d'art sur Twitch :).
Une conf qui date de 2016 (ou son upload sur youtube) du C3 explique les principes et utilité de Yosys, la différence et complément par rapport à un simulateur :
Bon, du coup, j'ai fait mes tests verilator (d'abord avec 2 exemples Hello World de verilator (le second avec systemc) pour comprendre les principes de base (un bout de code initialisateur en c++ + le code verilog) avec succès et effectivement, je ne m'attendais pas à quelque chose d'aussi simple en terme de programmation. J'ai aussi regardé et testé les exemples SDL + affichage pareil (et regardé les variantes matérielles).
Vu avec ces exemples simples ça ressemble à de la programmation classique sur un processeur déjà fait, mais sans cette couche. Il y a bien les réglages d'horloge, mais on retrouve aussi ça dès qu'on gère un périphérique en bas niveau après tout. Il me faut un FPGA pour voir les étapes suivantes maintenant.
C'est fou les sites spécialisés dans les modèles de processeurs FPGA (ou leur transcriptions en ASIC), j'ai vu efabless.com et opencores.org je ne m'attendais pas à cette foison d'implémentations.
Par rapport à cette remarque:
placement routage, la verif des timings et le bitstream
Là j'ai vu la contrainte du masque, et un passage sous forme géométrique du schéma avec la bibliothèque python eigen avec des schéma de liaison entre des cellules je ne sais pas si ce sont les LUT ou à un niveau plus élevé ? Désolé, pour la course au LUT, comme certains font pour les mégapixels sur APN, dans les précédente réponses. C'est important pour que les projets disponibles tiennent pour commencer, mais ça n'est clairement pas la seule contrainte.
Dans les exemples de la simulation VGA avec SDL il y a une gestion du timing pour vsync/hsync. j'utilisais en logiciel, mais c'est intéressant de voir comment c'est mis en place à ce niveau. Il y a des exemples de sprites matériels aussi (pas en SDL, il faudrait une implémentation du système de balayage dans la partie SDL de la simulation). Cela nécessite l'émission des pixels au bon moment à l'intérieur d'une ligne de balayage, je crois que c'est un exemple de bitstream, la sync n'étant donnée qu'en début de ligne ? je ne sais pas si cela correspond bien.
Je vois, oui effectivement, un dépôt, de recettes communautaires, sous formes de modules aiderait bien. Peut être qu'un site ou une base de donnée qui regrouperait les différents projets existants serait déjà un premier pas ? J'ai l'impression que c'est pareil pour Icarus dont il est question sur le site de Verilator et dans le lien vers l'ancien article Linuxfr.
Je suis tombé sur ce blog, qui explique comment utiliser SDL pour visualiser les sorties graphiques de FPGA via Verilator, il y a quelques articles sur le sujet de la géométrie et animations. Il parle d'apprentissage en une heure, ça fait rêver, je vais suivre son tuto :).
Par curiosité, c'est quel ouvrage ? J'en ai plusieurs mais je n'ai toujours pas trouvé l'Ouvrage de référence sur le sujet ;)
« Programming FPGAs - Getting Started with Verilog « de Simon Monk, je ne sais pas si c'est l'idéal, mais ça à l'air de faire le tour de ce que je voulais en tant que grand débutant:
* Ça part d'un petit rappel des portes logiques, des fliplop.
* Donne des exemples de cartes de dev (Elbert 2 (1.5KLUT), Mojo (9KLUT), Papilio (10KLUT), je ne prendrais certainement pas une de celles-ci, j'aimerais bien tester sur simulateur d'abord, mais je ne suis pas sûr que ça soit plus simple)
* Ça passe par la partie logicielle (sous Windows, donc, je n'utiliserais pas les mêmes logiciels, je suis sous Linux).
* Le timer, automate-fini => la base donc, et des exemples horloges/alarme)
* PWM et Servomoteur => trop bien pour les applis embarquées
* L'audio, générateur de ton, et lecteur d'échantillon => les bases pour faire un synthé
* La vidéo (avec sortie VGA, des exemples de tracés géométriques simples => implémenter un simple GPU
Yèp, par contre il y a plus petit en riscv : le SERV, c'est vrai qu'il est spécial cependant.
Ah, très bon, dans la doc ils parlent de Verilator, un simulateur, c'est exactement ce que je cherchais (je viens de le mettre, 22M le package, c'est raisonnable) et ça répond à ma question du dessus, donc grand merci j’espère pouvoir tester des ce soir :). Par contre, je n'ai pas trouvé le nombre de LUT de son implémentation.
Pas tout à fait, il est difficile à caser dans un petit gowin par exemple.
Je regardais justement sur des cartes Sipeed (je suis vraiment content de la longan nano (RISC-V32+écran), puisque c'est de la Tang Nano dont il est question, et je l'avais vu, effectivement. On doit pouvoir y faire rentrer que l'implémentation la plus limitée. Mais je pensais à la (lichee)Tang(primer) (pourquoi 2 noms??). Il y a une implémentation de picorv32 pour cette carte (Anlogic de 20KLUT), avec RT thread et en lien sur cette page de Humingbird (HBird E203), autre cœur RISC-V également avec RT Thread, je préférerais faire du bare-metal (il y a un lien vers une version bare-metal mais sur carte MXO2 de PicoRV32). Cela dit RT-Thread permet aussi d'éviter de refaire des choses de base, et probablement de tester plus facilement pour commencer. Il y a aussi la Tang Nano 4K (également Gowin) qui me fait de l'œil, avec son contrôleur RISC-V (au lieu du Cortex-M3), elle à 4608 LUT (au lieu de 1152) et un port HDMI. Elles sont toutes programmables avec openFPGALoader, mais d'après ce que je vois, ça à l'air d'être le cas de la majorité des cartes. Je ne sais pas si le microcontrôleur de la carte est utilisé uniquement comme programmateur, ou si on peut aussi l'utiliser pour du calcul et le FPGA comme extension. Dans ce cas j'en prendrait peut être une primer (pour la place restante) + une Nano 4K pour partir d'une base RISC-V. Elles sont toutes les deux <= 20€ ce qui me paraît raisonnable pour tester. Le simulateur suffira peut être pour commencer ?
Ah, oui, ça peut être intéressant. Du coup, je me suis lancé dans la lecture d'un ouvrage sur le développement sur FPGA, ça me démangeait depuis longtemps. J'en ai pris un générique pour comprendre un peu mieux toute la chaîne, celui que j'ai pris se base sur du Verilog, mais je suis ouvert aux autres langages pour le moment, j'ai vu que Chisel est un niveau au dessus et permet de gagner du temps dans le développement par rapport à Verilog, mais, l'expérience logicielle (archi informatique + assembleur + C/C++/etc + langages de script, m'a montré qu'il est toujours bon de comprendre le bas niveau pour une bonne conception haut niveau.
J'ai envie de m'amuser avec PicoRV32, une implémentation libre de RISC-V 32 bits pour FPGA, en Verilog, optimisé pour la taille. Avec ses 750 à 2000 LUT selon la configuration choisie ça lui permet de tenir sur n'importe quel FPGA et d'avoir encore de la marge pour expérimenter des co-processeurs ou extensions maison. Je ne me rend pas trop compte du travail que ça représente, mais sans s'y plonger, impossible de savoir. Dans tous les cas, ça sera une expérience amusante.
La partie émulation Android de Waydroid qui est une amélioration de Anbox pour Wayland, qui rend le tout fluide comme du linux natif (ça passe par du LXC), c'est libre et bien pratique pour les distros Linux.
Il utilise des composants de Mer, dont Jolla (SailFish OS) est le principal mainteneur il me semble ? Il y a libhybris aussi qui permet de bénéficier de pilotes écris que pour Android sous Linux.
Si vous êtes intéressé a intégrer le format SVG, comme Yoga est en python, il est possible d'intégrer facilement scour (il peut aussi s'appeler en ligne de commande). C'est lui qui est chargé de la sortie optimisée d'inkscape :
Bon, personnellement, je m'en passerait bien.
* Ils fournissent aussi de force un boîtier TV qui ne me sert à rien, et m'ont spammé pendant des années par tous les canaux (mail, boîte au lettre, téléphone fixe, téléphone mobile) pour Canal+ et son foot, ce dont je me contrefout. Ils auraient pris la peine de vérifier l'utilisation du boîtier TV, ils auraient vu qu'ils allaient perdre autant de temps qu'ils allaient m'en faire perdre. J'ai fini, après bien 10 ans de spam, par demander à un télé-spammeur de me retirer de leur listes, qui à pris ma demande en compte. Pour les mails ça partait dans le vide, quand je signalait aux autres que je ne regardait pas la télé ça partait dans le vide aussi.
* Ils me font changer de force de boîtier tous les 6 ou 7 ans, bon, je dis pas que c'est complétement mal, je suis passé d'un boîtier ADSL, à un boîtier ADSL2, puis à un boîtier ADSL2+ & fibre, bon, dans le dernier cas ça change rien je suis à la distance où le débit est identique à l'ADSL2, et la fibre, elle est connecté dans le vide dans le couloir depuis plus de 5 ans. Installation d'un autre opérateur qui a cru bon de mettre le boîtier de raccordement dans un immeuble voisin auquel on a naturellement pas accès, aucune cohésion entre les opérateur et leur n couches de sous-traitants. Je suis impressionné par le nombre de personnes pour qui ça pose un problème l'installation de la fibre (vive le libéralisme pour l'organisation des services vitaux :( ), je suis content d'avoir la paire de cuivre qui va jusqu'au centre des Postes, Télécommunications et Télégraphes le plus proche depuis probablement au moins un 1/2 siècle et qui fonctionne toujours. Le débit de l'ADSL2 me suffit largement pour ce que je fais.
Le dernier boîtier fait un bruit d'enfer au démarrage, probablement basé sur un processeur Intel, ils sont obligés de le ventiler. Ils ont du penser que c'était une bonne idée de mettre un écran illisible avec beau reflet en façade quand pas dans le noir :/ (les anciennes, lisibles avaient au moins l'avantage de faire horloge ). Je pense que je prendrais un routeur plus simple basé sur du RISC (ARM ou bientôt RISC-V ?) et ultra basse consommation qui ne fait que ça et probablement une interface CLI/web minimaliste pour la configuration si javais le choix.
Posté par tao popus .
En réponse à la dépêche Sortie de Ruby 3.0.
Évalué à 3.
Dernière modification le 30 août 2021 à 18:05.
En fait, c'est surtout un langage purement objet (et non orienté objet), ce qui inclus que tout soit typé par défaut. En même temps la philosophie de Ruby d'être souple dans son utilisation des objets est que chaque type d'objet a tendance à être accessible, grâce aux grand nombre de méthodes de conversions de type (cast), comme d'autres type d'objets, de façon relativement transparente et généralisée.
Donc je crois qu'on peut le considérer comme ayant un typage très fort (pur objet) et un typage très faible à la fois.
Je l'ai installé en version RISC-V il y a quelque mois, les mises à jour sont toujours présentes. C'est peut-être pas totalement officiellement supporté ?
ps. je crois que j'ai compris, il n'y a pas d'« ISO » tout prêt, il faut debootstraper, c'est la différence.
En général les téléphones sous Android supportent le clavier USB (via un adaptateur mâle<->femelle) en standard, comme c'est en standard dans le noyau Linux qu'il utilise. Certains constructeurs ou société de téléphonies qui aiment bien rajouter leur bugs maisons peuvent supprimer cette option, mais je crois que c'est assez rare. Il me semble que pas mal d'ereader sont sous Android ou du GNU/Linux bidouillé, donc ça devrait passer si il y a un port USB ? Si c'est un OS+noyau plus light et embarqué ce qui serait à la limite souhaitable, ça sera peut être plus compliqué ? En tout cas ça marchera plus que probablement sur le PineNote. Dommage qu'elle soit en n&b alors que plusieurs modèles couleurs pas trop mal sont dispo sur le marché. Je veux bien perdre du rafraîchissement pour avoir un outil portable de code/chat/… avec une bonne autonomie et qui ne bousille pas les yeux.
Je crois que le chapeau (que l'on voit dans liste des articles) et un peu bref, il pourrait indiquer un résumé de quelques éléments majeurs de l'article afin d'avoir une idée de ce qu'on va y lire et peut être avoir l'information concise des changements majeurs ? En l'état, ça ressemble à un Twitt, un texte vide de sens.
C'est dommage(able) parce que l'article est bien écrit et contient plein d'affirmation pertinentes. Au moins on ne peut pas accuser le chapeau d'être un texte trop aguicheur. Merci en tout cas pour toutes ces informations.
Et du coup il y a des piégés de Glimpse qui se manifestent, et quelqu'un pour dire (probablement bonne nouvelle, que c'est au point mort) ça me rappelle le squat (ici au sens opposé d'un squat qui sert réellement à des gens dans la difficulté) du code de ffmpeg par libav qui aurait fait perdre 4 ou 5 ans à pas mal de monde). Et tous les forks d'Audacity sont au sujet du coup. C'est assez trollesque, Twitter + le glimpsage aidant bien au troll.
De ce que je comprend par « scatter/gather » (en français disperser/rassembler), avoir des des données éparpillées au hasard et récupérer tout ça pour le traitement, c'est une bonne idée si on veut sortir des caches et multiplier les temps de calculs. Organiser les données en mémoire fait parti du travail d'optimisation d'une application.
Les mémoires des processeurs graphiques par exemple contiennent ce que l'on appelle en OpenGL des VBO (Vertex Buffer Object=Objet tampon de vecteurs), qui sont des tables de vecteurs. Le processeur graphique peut appliquer linéairement un changement sur l'ensemble des points d'un objet en une seule boucle. C'est le type de tampon qu'on initialise lors de la création de l'objet qui reste dans la carte graphique, et dont on charge le processeur graphique d'effectuer des traitements sur ses données.
Dans les premières version d'OpenGL on poussait tous les points dans la pile OpenGL à chaque image à générer (transfert de la ram principale vers la ram graphique) ce qui était vraiment contre-productif. De plus les données n'ont pas forcément à être modifiées systématiquement. Par contre à chaque rendu, le GPU va appliquer les transformations (rotation/échelle/déformation+perspective) sur l'ensemble des vecteurs de l'objet, qu'il appliquera via une boucle. Il en va de même dans quasiment tous les domaines je pense. Comme évoqué précédemment, chaîne de caractères, informations venant linéairement de capteurs, ou bien encore échantillon sonore, etc.
Le principe d'un processeur vectoriel est de définir, comme expliqué dans le document :
* Le type de donnée
* Une suite d'instruction à effectuer sur ce type de données dans une boucle
* la longueur de la boucle.
Et de laisser le processeur vectoriel effectuer cette boucle sur l'ensemble des données.
À la premier lecture les blocs de mémoire contenant les données seront mis en cache données et le processeur pourra boucler sur les données avec ces instructions contenues dans le cache instruction. On économise toutes les instructions d'incrémentation/chargement qui peuvent être fait en parallèle aux instructions de traitement avec un cycle d'avance.
Si on utilise ce type de processeur sur des données ponctuelles éparpillées la différence de cycle de traitement ne sera en revanche pas énorme, ça se joue à 2 ou 3 instructions comme montré dans les exemples, ce qui est négligeable par rapport au temps de lecture aléatoire en RAM ou dans des caches de niveaux intermédiaires. Ces cycles sont par contre à multiplier par le nombre de boucles dans le cas de données organisées pour un traitement linéaire.
Je crois qu'il y a un problème de compréhension du fonctionnement d'une unité vectorielle comme celle-ci. Le but est bien de traiter des ensemble de donnée en série.
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 2.
En en lisant plus j'ai compris que je n'avais pas compris (justement) quelque chose, en fait il faut le comptage est en cellules logiques != LUT. La LUT (table de vérité) n'en est qu'un élément, avec les flip-flop/latch (bascule D), les Mux et l'additionneur. Les organisations de ces éléments varient visiblement grandement d'un constructeur à l'autre avec leurs avantages et inconvénients en terme d'efficacité.
[^] # Re: Pas trop étonnant
Posté par tao popus . En réponse au journal Comme une impression de déjà vu…. Évalué à 4.
A bon, qu'est-ce qu'ils ont mis des années à implémenter que les autres avaient déjà? Quand xmpp est sorti, j'étais principalement sur le très vieux IRC comme la majorité des gens participant à des projets du libre, j'avoue que j'y suis retourné parce qu'il y avait plus de gens. Mais il y avait d'autres expériences intéressantes avec XMPP, comme les tableaux blancs (Inkscape, Coccinella, qui utilisaient ce protocole). La partie Inkscape n'a pas été maintenue puis abandonnée, et pareil pour Coccinella, c'est dommage. De cette époque XMPP est le seul protocole qui reste avec IRC. IRC reste l'outil principal dans le développement des plus gros projets libres, mais les serveurs XMPP de cette époque sont toujours actifs. Différents projets utilisent des plateformes plus fragmentées aujourd'hui (Telegram+Discord par exemple ou IRC+Matrix+Telegram via des ponts matrix qui existent depuis plusieurs années).
Il y a à présent Drawpile qui utilise son propre protocole pour le tableau blanc et d'autres outils qui passent par un serveur HTTP(s).
Personne n'a besoin d'être le numéro tant que ça sert son intérêt. Sur ce point, Le Fédiverse, avec un point supplémentaire pour tout ce qui tourne autour d'ActivityPub fonctionne déjà pas mal. Bon, c'est vrai que par contre, ça n'agglomère presque que des gens intéressants. Il semble qu'il y ai moins les guerres des Twitter & Facebook. Il y a des petites batailles de courte durée. Chacun se bloque de son côté quand il y a un désaccord profond entre 2 groupes et les autres continuent à converser. Il n'y a pas un blocage de la « main de dieu » (du roi ?). On retrouve donc sur le Fediverse une partie du publique d'IRC. Je reste dubitatif sur l’intérêt profond de ce genre de plateforme, moitié temps réel comme un chat, moitié web, permettant la relecture, et finalement, difficile à en tirer des informations pérennes. Je vois cela plutôt comme un outil intermédiare, plus étendu que des canaux spécialisés d'IRC qui compartimentent un peu, ce qui permet un peu plus d'échanges, et permet d'agglomérer des gens. C'est une étape intermédiaire permettant de diriger vers différents projet et leurs canaux de diffusions (chat sur irc, site web du projet, forge logicielle associée) qui permettent de pérenniser les idées et projets.
# Retour super intéressant
Posté par tao popus . En réponse au lien Les linuxiens et linuxiennes produisent plus de rapports de bogues et mieux. Évalué à 8.
Les retours de ce développeur sont vraiment intéressants je trouve. Il y a forcément le profil d'avantage hacker (dans le sens premier tu terme) de l'utilisateur Linux, mais ça serait encore plus intéressant d'aller plus loin et de connaître les profils des personnes.
Est-ce qu'elles sont plus efficace, parce que l'utilisation de Linux apprend à mieux comprendre le système, fourni plus d'aide, comme des logs plus explicites, avec un accès plus facile et mieux documenté, et l'aspect communautaire pousse à plus d'entre-aide ? D'un autre côté les utilisateurs de Windows habitués à cliquer sur des dizaine de OK à répétition sans rien lire ni comprendre, pousse au contraire à abandonner toute forme de compréhension.
Ou bien est-ce qu'il s'agît principalement de personnes travaillant dans le développement, dans l'admin, des profils à la base plus techniques ?
Si c'est le premier cas, c'est vraiment intéressant, cela voudrait dire que Linux répond à un besoin important d'éducation populaire et d'émancipation.
[^] # Re: Ce n'est pas une erreur humaine mais une erreur de process
Posté par tao popus . En réponse au lien OVH et la malheureuse « erreur humaine » qui a fait tomber des milliers de sites français. Évalué à 4.
Suivre des processus établis, ça réduit les chances d'erreur, mais c'est comme les feuilles administrative, il manque souvent la case correspondant au cas que l'on rencontre. Heureusement, les humains sont là pour mitiger les erreurs des processus.
C'est comme les checklist dans les procédure de vol, et le pilotage automatique (avion ou voiture), c'est toujours mieux quand l'humain peut couper les automatismes quand ils se mettent à buguer avec des problèmes liés à des cas jamais rencontrés.
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 2.
En avançant sur le sujet, je m'aperçoit que le microcontrôleur de la Tang est un Cortex-M et non un RISC-V. Il y a par contre bien un RISC-V sur la carte, un Bouffalo BL702 (basé sur un core RV32 de SiFive), mais il est utilisé pour le USB-série et le JTAG. Contrairement au ICE40, cette carte nécessite encore du proprio pour la conversion vers le bitstream (le code envoyé à la carte FPGA, cité dans l'article, je me demandais dans le précédent commentaire ce que c'était), mais le projet Apicula (et module python Apycula), au sein de Yosys justement, à pour but de libérer les FPGA Gowin/GW1N.
Et du coup, intéressant aussi, YoWASP un port des outils du projet Yosys en WASM, et l'utilisation de WASM en dehors du navigateur avec WASI de façon a avoir des outils portable. Je ne suis pas sûr que ce soit plus pertinent que Python. J'ai peur d'un gouffre à Mo avec les programmes qui rembarquent toutes les libs (à la JavaScript ou Rust et autre snap/appimage), plutôt que de réutiliser celles déjà installées comme on à l'habitude sous Linux. On vit sur une planète finie sur des ordis finis, avec toute leur entropie. Ça peut toujours dépanner dans certains cas (les outils de survie sur une clé usb de 256Go ou sur la carte SD tu téléphone branché en stockage de masse).
[^] # Re: Complément: explications de l'utilité de Yosys au C3
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 2.
OOps, désolé et merci pour ce lien. C'est vrai qu'ils ont aussi l'infra pour le streaming. Ils ont sauvé cette année une demoparty qui avait eu la mauvaise idée de passer par Twitch et c'est faite censuré parce qu'il y avait un dessin de nu dans une des démos. Mieux vaut ne pas montrer le Louvre ou n'importe quel autre musée d'art sur Twitch :).
# Complément: explications de l'utilité de Yosys au C3
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 3.
Une conf qui date de 2016 (ou son upload sur youtube) du C3 explique les principes et utilité de Yosys, la différence et complément par rapport à un simulateur :
Formal Verification of Verilog HDL with Yosys-SMTBMC (33c3).
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 3.
Bon, du coup, j'ai fait mes tests verilator (d'abord avec 2 exemples Hello World de verilator (le second avec systemc) pour comprendre les principes de base (un bout de code initialisateur en c++ + le code verilog) avec succès et effectivement, je ne m'attendais pas à quelque chose d'aussi simple en terme de programmation. J'ai aussi regardé et testé les exemples SDL + affichage pareil (et regardé les variantes matérielles).
Vu avec ces exemples simples ça ressemble à de la programmation classique sur un processeur déjà fait, mais sans cette couche. Il y a bien les réglages d'horloge, mais on retrouve aussi ça dès qu'on gère un périphérique en bas niveau après tout. Il me faut un FPGA pour voir les étapes suivantes maintenant.
C'est fou les sites spécialisés dans les modèles de processeurs FPGA (ou leur transcriptions en ASIC), j'ai vu efabless.com et opencores.org je ne m'attendais pas à cette foison d'implémentations.
Par rapport à cette remarque:
Dans les exemples de la simulation VGA avec SDL il y a une gestion du timing pour vsync/hsync. j'utilisais en logiciel, mais c'est intéressant de voir comment c'est mis en place à ce niveau. Il y a des exemples de sprites matériels aussi (pas en SDL, il faudrait une implémentation du système de balayage dans la partie SDL de la simulation). Cela nécessite l'émission des pixels au bon moment à l'intérieur d'une ligne de balayage, je crois que c'est un exemple de bitstream, la sync n'étant donnée qu'en début de ligne ? je ne sais pas si cela correspond bien.
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 3.
Je vois, oui effectivement, un dépôt, de recettes communautaires, sous formes de modules aiderait bien. Peut être qu'un site ou une base de donnée qui regrouperait les différents projets existants serait déjà un premier pas ? J'ai l'impression que c'est pareil pour Icarus dont il est question sur le site de Verilator et dans le lien vers l'ancien article Linuxfr.
Je suis tombé sur ce blog, qui explique comment utiliser SDL pour visualiser les sorties graphiques de FPGA via Verilator, il y a quelques articles sur le sujet de la géométrie et animations. Il parle d'apprentissage en une heure, ça fait rêver, je vais suivre son tuto :).
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 1.
Après vérification, Verilator est un compilateur de verilog vers C. Je ne suis pas sûr qu'on soit dans les mêmes conditions de ce fait.
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 5.
« Programming FPGAs - Getting Started with Verilog « de Simon Monk, je ne sais pas si c'est l'idéal, mais ça à l'air de faire le tour de ce que je voulais en tant que grand débutant:
* Ça part d'un petit rappel des portes logiques, des fliplop.
* Donne des exemples de cartes de dev (Elbert 2 (1.5KLUT), Mojo (9KLUT), Papilio (10KLUT), je ne prendrais certainement pas une de celles-ci, j'aimerais bien tester sur simulateur d'abord, mais je ne suis pas sûr que ça soit plus simple)
* Ça passe par la partie logicielle (sous Windows, donc, je n'utiliserais pas les mêmes logiciels, je suis sous Linux).
* Le timer, automate-fini => la base donc, et des exemples horloges/alarme)
* PWM et Servomoteur => trop bien pour les applis embarquées
* L'audio, générateur de ton, et lecteur d'échantillon => les bases pour faire un synthé
* La vidéo (avec sortie VGA, des exemples de tracés géométriques simples => implémenter un simple GPU
Ah, très bon, dans la doc ils parlent de Verilator, un simulateur, c'est exactement ce que je cherchais (je viens de le mettre, 22M le package, c'est raisonnable) et ça répond à ma question du dessus, donc grand merci j’espère pouvoir tester des ce soir :). Par contre, je n'ai pas trouvé le nombre de LUT de son implémentation.
Je regardais justement sur des cartes Sipeed (je suis vraiment content de la longan nano (RISC-V32+écran), puisque c'est de la Tang Nano dont il est question, et je l'avais vu, effectivement. On doit pouvoir y faire rentrer que l'implémentation la plus limitée. Mais je pensais à la (lichee)Tang(primer) (pourquoi 2 noms??). Il y a une implémentation de picorv32 pour cette carte (Anlogic de 20KLUT), avec RT thread et en lien sur cette page de Humingbird (HBird E203), autre cœur RISC-V également avec RT Thread, je préférerais faire du bare-metal (il y a un lien vers une version bare-metal mais sur carte MXO2 de PicoRV32). Cela dit RT-Thread permet aussi d'éviter de refaire des choses de base, et probablement de tester plus facilement pour commencer. Il y a aussi la Tang Nano 4K (également Gowin) qui me fait de l'œil, avec son contrôleur RISC-V (au lieu du Cortex-M3), elle à 4608 LUT (au lieu de 1152) et un port HDMI. Elles sont toutes programmables avec openFPGALoader, mais d'après ce que je vois, ça à l'air d'être le cas de la majorité des cartes. Je ne sais pas si le microcontrôleur de la carte est utilisé uniquement comme programmateur, ou si on peut aussi l'utiliser pour du calcul et le FPGA comme extension. Dans ce cas j'en prendrait peut être une primer (pour la place restante) + une Nano 4K pour partir d'une base RISC-V. Elles sont toutes les deux <= 20€ ce qui me paraît raisonnable pour tester. Le simulateur suffira peut être pour commencer ?
[^] # Re: Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 3. Dernière modification le 05 octobre 2021 à 12:41.
Ah, oui, ça peut être intéressant. Du coup, je me suis lancé dans la lecture d'un ouvrage sur le développement sur FPGA, ça me démangeait depuis longtemps. J'en ai pris un générique pour comprendre un peu mieux toute la chaîne, celui que j'ai pris se base sur du Verilog, mais je suis ouvert aux autres langages pour le moment, j'ai vu que Chisel est un niveau au dessus et permet de gagner du temps dans le développement par rapport à Verilog, mais, l'expérience logicielle (archi informatique + assembleur + C/C++/etc + langages de script, m'a montré qu'il est toujours bon de comprendre le bas niveau pour une bonne conception haut niveau.
J'ai envie de m'amuser avec PicoRV32, une implémentation libre de RISC-V 32 bits pour FPGA, en Verilog, optimisé pour la taille. Avec ses 750 à 2000 LUT selon la configuration choisie ça lui permet de tenir sur n'importe quel FPGA et d'avoir encore de la marge pour expérimenter des co-processeurs ou extensions maison. Je ne me rend pas trop compte du travail que ça représente, mais sans s'y plonger, impossible de savoir. Dans tous les cas, ça sera une expérience amusante.
# Grand merci !
Posté par tao popus . En réponse à la dépêche Sortie de la version 0.10 de Yosys . Évalué à 4.
Merci pour ce bel aperçu global, des détails et des exemples qui permettent de mieux appréhender les différents éléments du développement d'un CI.
[^] # Re: Risque de déconvolution ?
Posté par tao popus . En réponse au journal Deface: flouter simplement et automatiquement les visages dans une vidéo. Évalué à 3.
Comme certains ont répondu plus haut, le carré noir.
[^] # Re: OSEF
Posté par tao popus . En réponse à la dépêche Premier coup d'œil à SailfishOS 4.2.0 (Verla) . Évalué à 3.
La partie émulation Android de Waydroid qui est une amélioration de Anbox pour Wayland, qui rend le tout fluide comme du linux natif (ça passe par du LXC), c'est libre et bien pratique pour les distros Linux.
Il utilise des composants de Mer, dont Jolla (SailFish OS) est le principal mainteneur il me semble ? Il y a libhybris aussi qui permet de bénéficier de pilotes écris que pour Android sous Linux.
# SVG ?
Posté par tao popus . En réponse à la dépêche YOGA Image Optimizer v1.1 : résultats des travaux de l'été. Évalué à 4.
Si vous êtes intéressé a intégrer le format SVG, comme Yoga est en python, il est possible d'intégrer facilement scour (il peut aussi s'appeler en ligne de commande). C'est lui qui est chargé de la sortie optimisée d'inkscape :
https://github.com/scour-project/scour
[^] # Re: Et chez nous ?
Posté par tao popus . En réponse à la dépêche Les Néerlandais peuvent choisir leurs modems et routeurs. Évalué à 7.
Bon, personnellement, je m'en passerait bien.
* Ils fournissent aussi de force un boîtier TV qui ne me sert à rien, et m'ont spammé pendant des années par tous les canaux (mail, boîte au lettre, téléphone fixe, téléphone mobile) pour Canal+ et son foot, ce dont je me contrefout. Ils auraient pris la peine de vérifier l'utilisation du boîtier TV, ils auraient vu qu'ils allaient perdre autant de temps qu'ils allaient m'en faire perdre. J'ai fini, après bien 10 ans de spam, par demander à un télé-spammeur de me retirer de leur listes, qui à pris ma demande en compte. Pour les mails ça partait dans le vide, quand je signalait aux autres que je ne regardait pas la télé ça partait dans le vide aussi.
* Ils me font changer de force de boîtier tous les 6 ou 7 ans, bon, je dis pas que c'est complétement mal, je suis passé d'un boîtier ADSL, à un boîtier ADSL2, puis à un boîtier ADSL2+ & fibre, bon, dans le dernier cas ça change rien je suis à la distance où le débit est identique à l'ADSL2, et la fibre, elle est connecté dans le vide dans le couloir depuis plus de 5 ans. Installation d'un autre opérateur qui a cru bon de mettre le boîtier de raccordement dans un immeuble voisin auquel on a naturellement pas accès, aucune cohésion entre les opérateur et leur n couches de sous-traitants. Je suis impressionné par le nombre de personnes pour qui ça pose un problème l'installation de la fibre (vive le libéralisme pour l'organisation des services vitaux :( ), je suis content d'avoir la paire de cuivre qui va jusqu'au centre des Postes, Télécommunications et Télégraphes le plus proche depuis probablement au moins un 1/2 siècle et qui fonctionne toujours. Le débit de l'ADSL2 me suffit largement pour ce que je fais.
Le dernier boîtier fait un bruit d'enfer au démarrage, probablement basé sur un processeur Intel, ils sont obligés de le ventiler. Ils ont du penser que c'était une bonne idée de mettre un écran illisible avec beau reflet en façade quand pas dans le noir :/ (les anciennes, lisibles avaient au moins l'avantage de faire horloge ). Je pense que je prendrais un routeur plus simple basé sur du RISC (ARM ou bientôt RISC-V ?) et ultra basse consommation qui ne fait que ça et probablement une interface CLI/web minimaliste pour la configuration si javais le choix.
[^] # Re: endless methods
Posté par tao popus . En réponse à la dépêche Sortie de Ruby 3.0. Évalué à 3.
Dommage de ne pas avoir copié cette exemple dans l'annonce de LinuxFR.
[^] # Re: Typage fort
Posté par tao popus . En réponse à la dépêche Sortie de Ruby 3.0. Évalué à 3. Dernière modification le 30 août 2021 à 18:05.
En fait, c'est surtout un langage purement objet (et non orienté objet), ce qui inclus que tout soit typé par défaut. En même temps la philosophie de Ruby d'être souple dans son utilisation des objets est que chaque type d'objet a tendance à être accessible, grâce aux grand nombre de méthodes de conversions de type (cast), comme d'autres type d'objets, de façon relativement transparente et généralisée.
Donc je crois qu'on peut le considérer comme ayant un typage très fort (pur objet) et un typage très faible à la fois.
# Un total de neuf architectures sont gérées=> Et RISC-V????
Posté par tao popus . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 1. Dernière modification le 24 août 2021 à 15:45.
Je l'ai installé en version RISC-V il y a quelque mois, les mises à jour sont toujours présentes. C'est peut-être pas totalement officiellement supporté ?
ps. je crois que j'ai compris, il n'y a pas d'« ISO » tout prêt, il faut debootstraper, c'est la différence.
# Clavier USB et Android
Posté par tao popus . En réponse au journal Opensource et e-ink. Évalué à 6.
En général les téléphones sous Android supportent le clavier USB (via un adaptateur mâle<->femelle) en standard, comme c'est en standard dans le noyau Linux qu'il utilise. Certains constructeurs ou société de téléphonies qui aiment bien rajouter leur bugs maisons peuvent supprimer cette option, mais je crois que c'est assez rare. Il me semble que pas mal d'ereader sont sous Android ou du GNU/Linux bidouillé, donc ça devrait passer si il y a un port USB ? Si c'est un OS+noyau plus light et embarqué ce qui serait à la limite souhaitable, ça sera peut être plus compliqué ? En tout cas ça marchera plus que probablement sur le PineNote. Dommage qu'elle soit en n&b alors que plusieurs modèles couleurs pas trop mal sont dispo sur le marché. Je veux bien perdre du rafraîchissement pour avoir un outil portable de code/chat/… avec une bonne autonomie et qui ne bousille pas les yeux.
[^] # Re: Génial le chapeau
Posté par tao popus . En réponse à la dépêche Laravel 8 est sorti. Évalué à 3.
Je crois que le chapeau (que l'on voit dans liste des articles) et un peu bref, il pourrait indiquer un résumé de quelques éléments majeurs de l'article afin d'avoir une idée de ce qu'on va y lire et peut être avoir l'information concise des changements majeurs ? En l'état, ça ressemble à un Twitt, un texte vide de sens.
C'est dommage(able) parce que l'article est bien écrit et contient plein d'affirmation pertinentes. Au moins on ne peut pas accuser le chapeau d'être un texte trop aguicheur. Merci en tout cas pour toutes ces informations.
[^] # Re: Cool, Snowden va pouvoir financer...
Posté par tao popus . En réponse à la dépêche Financer les développeurs de GIMP pour un développement pérenne. Évalué à 2.
Et du coup il y a des piégés de Glimpse qui se manifestent, et quelqu'un pour dire (probablement bonne nouvelle, que c'est au point mort) ça me rappelle le squat (ici au sens opposé d'un squat qui sert réellement à des gens dans la difficulté) du code de ffmpeg par libav qui aurait fait perdre 4 ou 5 ans à pas mal de monde). Et tous les forks d'Audacity sont au sujet du coup. C'est assez trollesque, Twitter + le glimpsage aidant bien au troll.
https://nitter.nixnet.services/Snowden/status/1416778909358731266#m
[^] # Re: Et RISC-V?
Posté par tao popus . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 5.
De ce que je comprend par « scatter/gather » (en français disperser/rassembler), avoir des des données éparpillées au hasard et récupérer tout ça pour le traitement, c'est une bonne idée si on veut sortir des caches et multiplier les temps de calculs. Organiser les données en mémoire fait parti du travail d'optimisation d'une application.
Les mémoires des processeurs graphiques par exemple contiennent ce que l'on appelle en OpenGL des VBO (Vertex Buffer Object=Objet tampon de vecteurs), qui sont des tables de vecteurs. Le processeur graphique peut appliquer linéairement un changement sur l'ensemble des points d'un objet en une seule boucle. C'est le type de tampon qu'on initialise lors de la création de l'objet qui reste dans la carte graphique, et dont on charge le processeur graphique d'effectuer des traitements sur ses données.
Dans les premières version d'OpenGL on poussait tous les points dans la pile OpenGL à chaque image à générer (transfert de la ram principale vers la ram graphique) ce qui était vraiment contre-productif. De plus les données n'ont pas forcément à être modifiées systématiquement. Par contre à chaque rendu, le GPU va appliquer les transformations (rotation/échelle/déformation+perspective) sur l'ensemble des vecteurs de l'objet, qu'il appliquera via une boucle. Il en va de même dans quasiment tous les domaines je pense. Comme évoqué précédemment, chaîne de caractères, informations venant linéairement de capteurs, ou bien encore échantillon sonore, etc.
Le principe d'un processeur vectoriel est de définir, comme expliqué dans le document :
* Le type de donnée
* Une suite d'instruction à effectuer sur ce type de données dans une boucle
* la longueur de la boucle.
Et de laisser le processeur vectoriel effectuer cette boucle sur l'ensemble des données.
À la premier lecture les blocs de mémoire contenant les données seront mis en cache données et le processeur pourra boucler sur les données avec ces instructions contenues dans le cache instruction. On économise toutes les instructions d'incrémentation/chargement qui peuvent être fait en parallèle aux instructions de traitement avec un cycle d'avance.
Si on utilise ce type de processeur sur des données ponctuelles éparpillées la différence de cycle de traitement ne sera en revanche pas énorme, ça se joue à 2 ou 3 instructions comme montré dans les exemples, ce qui est négligeable par rapport au temps de lecture aléatoire en RAM ou dans des caches de niveaux intermédiaires. Ces cycles sont par contre à multiplier par le nombre de boucles dans le cas de données organisées pour un traitement linéaire.
[^] # Re: Et RISC-V?
Posté par tao popus . En réponse à la dépêche Sortie du noyau Linux 5.13. Évalué à 6.
Je crois qu'il y a un problème de compréhension du fonctionnement d'une unité vectorielle comme celle-ci. Le but est bien de traiter des ensemble de donnée en série.
Voici une présentation de 2015 à ce sujet qui explique les avantages du processeur vectoriel traditionnel par rapport au packed-SIMD et quelques améliorations apportées dans le cas de l'extension vectorielle de RISC-V :
https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf