Selso a écrit 134 commentaires

Salut.
Grand merci pour prendre le temps de me répondre.
Je vais essayer de clarifier mes questions.

…
En pratique, la taille des venvs séparés n'est pas si problématique, surtout que les bibliothèques Python sont pour la plupart écrites en Python, donc pas compilées, ce qui fait que la taille du code (je veux dire le poids des fichiers .py) est relativement petite
…

D'accord ok mais du coup cela ne pose-t-il pas un pb d'orchestrer l'ensemble qui fonctionne dans des environnements séparés ? si mon application dépend de lib1 dans env1 (et qui partagerait cet environnement, pour faire plus simple), et de lib2 dans env2, combien ai-je d’interpréteurs lancés ? Faut-il des mécanismes particuliers pour partager les données s'il y en a plusieurs ? Ou alors je suis a côté de la plaque et l'env est complètement transparent pour au runtime.

Par ailleurs comme tu le soulignes pour les distributions linux, on n'utilise pas directement pip pour installer les paquets mais la distribution qui bénéficient du travail de ces mainteneurs. Cela rendrait l'utilisation de pipx superflue dans ce cas non ?
Quand à l'espace disque utilisé : il me semble que python laisse un fichier compilé des modules lancés, ce qui multiplie l'espace utilisé.
Je viens de l'embarqué, l'optimisation de l'espace disque reste un critère dans les choix de design. C'est moins le cas pour des applications desktops.

Pas forcément : requirements.txt est un format possible (mais limité) pour les lock files. Poetry et PDM produisent des lock files dans des formats différents qu'ils comprennent chacun.

Alors le lock file est il un fichier pour le "packageur" ou l'utilisateur ?

Et finalement ces outils vont quand même créer un package installable avec pip ou conda ? ou conda est-il exclusif à son écosystème ?
Je ne suis pas sûr de comprendre la question.

Est-ce que la finalité de ces différents backend c'est de pousser les paquets sur pypi ? Il me semble que pour anaconda il s'agit d'une autre distribution python ?
A quel point ces outils sont interopérables sur les distributions ?
Mais tu as déjà répondu pour conda : "oui mais dans un seul sens et si…"

Est-ce que l'on ne pourrait pas redistribuer les solutions selon la complexité de l'application à packager, ou se trouve-t-on trop rapidement embarquée dans les successions de dépendances ?
Désolé, je ne comprends pas la question, pourrais-tu reformuler ?

Tu réponds un peu déjà à la question juste au dessus. Le choix du build backend dépend aussi de la source des paquets.

En fait j'essaie de compiler en tête les critères pour sélectionner un backend plutôt qu'un autre, dans une sorte de table tu vois.
Bêtement je pensais utiliser pyinstaller pour un truc très simple à fournir à un utilisateur non-developpeur. Mais visiblement on propose cet outil pour freezer plus que pour distribuer un package, même si pyinstaller génèrerait les bons fichiers pour.
Ensuite dans la plupart des cas on utiliserait hatching car il est proposé par défaut dans le tuto du site pypi.

J'ai une connaissance qui a utilisé poetry, visiblement à cause de la complexité des dépendances de l'application utilisé. Je prends peut-être un raccourci, mais genre si la gestion du packaging est est complexe a cause des dépendances alors prends poetry qui t'évitera les accidents.

Ensuite j'ai l'impression qu'anaconda vise un milieu bien particulier pour les applications : une simple recherche google et dans le résumé du lien je lis : "Python/R data science and machine learning on a single machine".

Hello,

Encore un excellent article merci. Ci dessous un retour à chaud.
En ce qui me concerne je suis toujours indécis sur quoi utiliser finalement, enfin je sens une légère préférence vers hatch. Ce n'est pas un reproche à l'article, car ce n'est pas ce que tu proposes.

pipx : un venv par module ?! Doit-on en arriver là ? On parvient bien à faire une distri linux sans dupliquer les dépendances de chaque lib ou outil.
Le lock file pas vraiment compris, je vais devoir relire… ah ok c'est un fichier requirements.txt
Et finalement ces outils vont quand même créer un package installable avec pip ou conda ? ou conda est-il exclusif à son écosystème ?
Est-ce que l'on ne pourrait pas redistribuer les solutions selon la complexité de l'application à packager, ou se trouve-t-on trop rapidement embarquée dans les successions de dépendances ?

J'ai cliqué 20 mais c plutôt 18, après avoir retrouvé cette info sur mon compte.
J'essaie de mon souvenir de l'article le plus ancien dont je me souviens, je dirais quand le technico-commercial de mon ancienne boite avait publié un article sur Yocto. Moins sûr mais plus ancien, un article sur kicad qui m'avait impressionné à l'époque. Un gars qui s'est dit je vais apprendre le C++/OpenG, et il pond ça !

L'explication pointant le "sachant" / big guy m'a convaincu.

Le C/C++ nécessite de maitriser la chaine de compilation ce qui nécessite d'autres compétences.
Il nécessite aussi une certaine maîtrise du pré-processeur qui a aussi sa syntaxe.
Et si tu veux faire des
tu n'as encore rien fait qu'il te faut maitriser deux outils en plus du langage.

Python est basé sur un interpréteur c'est déjà un plus dans la simplification sur l'utilisation.
Aussi je vois C/C++ comme des langages de "manipulation" de données en mémoire, à peine structurées (bon plus pour le C++ mais le templating c'est pas une notion si simple à maîtriser).

Python est bien plus avancé pour la manipulation de données et permet leur introspection sans passer par le debugger.
Pour arriver son niveau avec le C/C++ il faut ajouter des dépendances sur d'autres bibliothèques, et là aussi le lien est moins évident qu'avec Python.

J'ai pris ça comme une sérieuse blague.
Mais si tu as des sources merci des les partager.

Le packaging python m'a toujours laissé perplexe, encore plus quand j'ai découvert qu'il y avait aussi conda.
A chaque fois un gros WTF me remplit les poumons. J'ai à peine commencer à me familiariser avec un outil qu'un autre se pointe. Cette introduction met la lumière sur cette foire.
Pourquoi conda serait plus adapté pour le packet wheel ? Et pourquoi appeler ça wheel ?
Que faut il utiliser à la fin ?
J'espère des réponses dans la suite de cette série d'article.

Je me pose la question d'avoir choisi ArchiLinux, plutôt que Yocto pour la distribution.
Aussi l'on parle beaucoup d'AMD, est-ce qu'à la longue on aura le driver opensource mieux supporté que le propriétaire.
Autrement, je trouve que ça peut être l'opportunité de proposer un "standard ouvert" pour la distribution d'applications pour ces appareils.
A suivre.

J'ai parcouru vite fait ses faits et la traque. C'est qu'une première impression mais :
- Il a bien joué au petit délinquant quand même.
- Il a bien mis "vénère" son confrère Tsutomu Shimomura qui est allé jusqu'à arpenter les rues pour le retrouver avec le FBI.
- Sa première arrestation, il la doit à une "trahison" d'un collègue à qui il a joué un mauvais tour.
- Soit il se croyait trop malin, soit il était trop idiot pour réaliser les conséquences de ses actes envers les personnes de son milieu
- L'ironie du sort est qu'il est apparemment à l'origine du social engineering, donc entre autre du comportement humain.

J'aurai pensé qu'il aurait mal fini a cause de ses pratiques, mais non il a été victime d'un piratage de ses cellules par le cancer du pancréas. Triste.

Un sacré phénomène pour moi.

Anki cité ci-dessus est un super outil d'apprentissage, pour qui veut apprendre.
J'aimerais bien qu'il supporte Google Auto, pour les longues routes que je fais la semaine…

Je ne connaissais pas Vosk, j'ai utilisé Sphynx avec de très mauvais résultats (micro ou engine, ou les deux en cause).
J'avais écris un petit programme pour tester la prononciation.

En lisant un peu mieux je vois que SpeakRecognition wrap Sphynx et Vosk, comme quoi il faut prendre le temps de lire.

Merci, ça me relance dans l'aventure :)

A 20 ans je voyais des mandrake courir les rues,
Mais j'ai réellement commencé en double boot avec une Suse 8 (version pas sûr) qui était "la distro officielle" de la boite. Avec fvwm en windows manager (ça faisait de la place à l'écran).
Puis debian, puis je fais le fainéant avec une Ubuntu.
Je me serai bien laissé tenté par Arch, ils ont une communauté bien réactive sur le chat.
cdlt,

Hello,

Déjà avoir quelque chose sur FPGA qui fonctionne sera génial. Mais est-ce que ce prototype sur FPGA donnera une bonne vision du potentiel de ces choix d'architecture ?
Est-ce qu'on pourra lui donner une comparaison plausible si on le produisait avec une gravure équivalente aux puces du marché ?
Merci pour le partage dans tous les cas.

Ah bah merci je vais encore y passer des heures au lieu de m'occuper de mes travaux !
Ma liste de jeu steam va devoir attendre rsssss….

oui tu sous entends que c'est un pb car la VRAM est toujours en moindre quantité que la ROM.
oui avec la VRAM on peut faire de l'image calculée. Peut-être pas suffisamment exploitée. Mais alors pourquoi ce choix ? La RAM c'est cher.
j'avais jamais tilté que la ROM n'était pas accessible, aujourd'hui tout est est plat dans l'espace d'adressage. Cela aurait été pratique pour gérer un background par exemple.

Je savais pas que la neo-geo avec son NDK
Je savais pas qu'un développeur web pouvait faire autant sur de l'embarqué, et encore moins s'intéresser au méandre d'un microprocesseur. :D

Merci pour cette interview. Toujours intéressants ce sujet des kits pour consoles.
La prochaine le fameux CD qui by-passait le bios de la dreamcast ?

J'ai testé la version histoire principale (2015).
Elle est bien construite on se laisse prendre, des graphismes un peu dépassés pour certains mais pas gênant pour un fan de retro comme moins. Ils sont cohérents et m'on fait baigner dans l'atmosphère médiévale recherchée. La prise en main est assez rapide.
La difficulté de l'IA est bien dosée dans mon souvenir.
Je recommande à tous les aficionados des jeux de stratégies de l'essayer une fois, vous passerez un bon moment.

Pour ce qui est de l'expérience de dev, c'est à voir. C'est dans ma liste de possibilités si un jour j'y arrive.

Ca vaut ce que ca vaut mais j'ai eu l'opportunité de me pencher sur la question lorsque j'ai voulu implémenter un petit serveur avec un zotac AMD vs un macbook pro 2009 (intel). J'ai utilise un de ces watmetres avec prise mural.
Sans rien faire niveau conso le macbook faisait mieux.
J'ai ensuite installé TLP sur le zotac et forcé le mode batterie pour arriver dans les même conditions de consommation.

L'optimisation de la consommation est loin de se concentrer sur le CPU, preuve en est cette page ArchWiki sur le sujet.

Mais dans ces essais j'ai trouvé beaucoup de réponse côté Intel. J'en ai déduis que ce n'était pas un critère différenciant AMD / Intel.

Le mieux classé pour moi serait ARM, cela expliquerait pourquoi c'est l'architecture la plus utilisée dans les mobiles et embarqué ;).

Encore surpris que l'on arrive à faire de telles fournitures pour ces consoles.
Merci !
J'adore cette tendance de linuxfr a proposer des interviews a ces personnes qui ont beaucoup à partager.

un peu à la manière de : VCV RAck

Pour le point 35 je suis plus partagé.
Tout déclarer en début de fonction c'est aussi une bonne métrique pour vérifier la complexité.
Si tu dépasses les 5 variables et qu'en plus certaines de celles-ci ont une utilisation éloignée dans le code, il faudrait penser à refactoriser.
On peut exclure les variables d'itération de cette considération et suivre le principe expliqué dans l'article d'origine.

• prétendre répliquer 3 fois les données alors que celles-ci restent dans le même datacenter est un peu du foutage de gueule (je reformule)

Par défaut sur Azure (Microsoft) on vous propose le moins cher le sotckage LRS (local redondant Storage), à savoir 3 copies différentes dans un même datacenter. Cela prévient contre les pannes disques c'est tout.
La redondance datacenter et régionale ça se demande et ça se paie.

Il faudrait lire le détail du SLA et du niveau demandé par le demandeur lors de la contractualisation du service.

Aaaaah ben il n'y a pas à lire tant que ça pour comprendre :

"Les dispositions relatives au service de backup automatisé indiquent que la SAS OVH s’engage à ce que l’espace de stockage alloué à l’option de backup soit physiquement isolé de l’infrastructure dans laquelle est mis en place le serveur privé virtuel du client."
Et plus loin :
"La SAS OVH soutient que la SAS FRANCE BATI COURTAGE aurait mal compris ou mal interprété le contrat relatif à la sauvegarde automatique. La mauvaise foi et le manque de loyauté de la SAS OVH sont ici patents."

Le point positif que je vois en me basant seulement sur la note, c'est que les tribunaux dénoncent les clauses abusives.
Aussi je vois que lorsqu'il y a un enjeu sur le contrat, il vaut mieux se mettre d'accord en amont sur le dédommagement, ou s'y préparer. Il y a un gros gap entre la demande et la décision de justice.

Maintenant je me demande quel niveau de sécurité offre OVH sur son backup. C'est tellement plus simple de le définir avec Azure.
Je pense qu'OVH a perdu de la clientèle pro en plus de cette somme.

J'ai coché le dernier, mais effectivement et par défaut pour tout le monde le DAC.
Cela évoque du monde de s'ajouter au groupe wheel ou dialout, u un groupe Docker ?
Avec udev et et systemd on a aussi des bases proposées.
C'est toujours dispo sur la distribution.
J'ai lu que app armor était aussi activé sous Ubuntu en mode complain, mais pas constaté sous WSL.
J'ai l'impression que certains de ces outils sont plus plébiscités par certaines distributions que d'autres ?
Pas considéré comme une véritable sécurité mais la virtualisation et la containérisation sont aussi des moyens d'isolation.

Est-ce que quelqu'un connaît aussi "Trusted execution environment (TEE)" ?

On utilise tout cela sans vraiment le comprendre c'est dommage (d'un point de vue dev).

Quite à mettre la puce pour la compatibilité mentionnée plus bas, autant qu'elle fasse quelque chose. C'est pas non plus le summum de la complexité si tu compares aux architectures actuelles où même des cables d'alimentations de laptops sont équipés de processeurs bien plus puissant que ce 68000.

Je ne comprends pas ces comparaisons. La question est de synchroniser des CPUs/contrôleur. C'est toujours un point délicat. Les logs du SGDK en témoignent.

De fait, la Master System a continué à être vendue en parallèle pendant des années comme console d'entrée de gamme, jusqu'en 1996 avec l'arrivée de la Saturn et jusqu'en 2016 (!) au Brésil.

A Chaque pays son marché. Celui du Brésil ne fonctionne pas à la même vitesse que le notre (j'y ais été un certain temps pour le voir). Mais si on continue à vendre une console en entrée de gamme, pourquoi faire un adaptateur ? En tout cas je ne connaissais pas cet accessoire à l'époque.

Je pense qu'il aurait été plus profitable à Sega de permettre aux possesseurs de MegaDrive de pouvoir jouer directement aux jeux master system sans adaptateur.

Proposer de la retro-compatibilité dans l'architecture HW principale, ça pose de sérieuses contraintes. Mais la encore le marché du jeu de la master system aurait concurrencé celui de la console.

On refera pas la console et on pourra avoir des avis différents sur le marketing.
Mais les Homebrews avec le SGDK montrent qu'elle en avait dans le ventre. Un toolkit de cette qualité à l'époque aurait pu changer la donne.

La puce z80 qui était le coeur de la master system, gère sur la megadrive les 2 puces sonores.

Ca en fait des puces… et donc de la complexité et des problèmes.
Quand on sait la puissance du 68000 j'ai du mal à comprendre cette délégation de la gestion.

Ça peut être un bon argument de vente de pouvoir continuer à utiliser sa logithèque sur la nouvelle console, et de revendre l'ancienne

Je n'ai jamais vu cette extension. Avec une méga drive je doute que l'on avait envie d'acheter un jeu master system. A voir le cout de l'adaptateur, peut-être aussi couteux à l'époque qu'une master d'occasion.

Quand on voit l'histoire des consoles de Sega, on ne peut que déplorer les problèmes d'architecture hardware, avec des architectures qui ne permettent pas la pleine exploitation de leur système.

La console s'en est bien tirée face à sa concurrente.

Ca fait vraiment plaisir de lire cet inverview.
Je suis petit contributeur patreon a ce projet.
En tant que développeur embarqué je trouve le travail remarquable, comme avec l'optimisation du build et l'abstraction du packaging du firmware.

Le kit va plus loin qu'une toolchain pour build, il y a des outils pour faciliter l'intégration de vos ressources graphiques.
Un aide aussi au lancement en mode debug serait peut-être souhaitable.
Mais c'est déjà un énorme travail.

C’est d’autant plus dommage qu’à la base le VDP a été conçu pour accueillir 4 + 4 palettes en RGB444 mais pour des raisons de coût ça a été tronqué à 4 palettes partagées en RGB333.

Tout à fait d'accord. Le manque de couleur est l'argument des détracteurs de la console à l'époque avec ce côté terne, voir viellot. Et l'alpha-blending qui manque pour une gestion de la transparence. Si la raison de ce choix était économique, cela rend la dispo de deux chips de son tout à fait absurde. Je crois que c'était pour des raisons de compatibilité avec la master system, mais là encore un mauvais choix de Sega. Ils ont pas été bons sur la stratégie hardware.

produire un pseudo-mode bitmap

Je vois pas vraiment ce que ça peut donner, à par l'effet de l'eau géré dans Sonic 2 souvent cité en exemple.

Déjà son CPU central - le 68000 - a de la ressource !

Oui dans le monde du système embarqué c'était une référence avant l'arrivée de l'ARM. Il existe des OS temps réel dessus.

Mais vu que je ne joue plus aujourd’hui, il est assez probable que je repasse à Linux.

Ca serait une bonne nouvelle, pour un support natif du build dans l'environnement d'origine de gcc. Il y a bien une contribution externe basée sur docker, mais je trouve que l'on y gagnerait à avoir une fourniture avec une source bien identifiée.

Un super homebrew que j'aimerai bien expérimenter sur Hackaday : https://hackaday.io/project/1507-usb-megadrive-devkit

C'est intéressant. C'est peut-être même utilisé par les dev du projet pour débogger leurs interfaces, avec un outil tiers comme wireshark.