kif a écrit 19 commentaires

Salut,

Super article, on attend le tome 3 avec impatience …

Concernant la résolution des dépendances, il faut citer le projet mamba qui est une version de conda avec le même solveur ré-écrit en C(++?) et parallèlisé. Ça s'utilise tout pareil que conda mais c'est au moins 3x plus rapide. Pour ceux qui ne veulent pas changer du tout, on peut même utiliser conda avec le solveur de mamba…

Meilleurs vœux pour 2024

Jérôme

Sans le "demontrer", suffit de compter le nombre de lignes de code. Je crois me souvenir qu'il y a presque un facteur 5 en taille/LOC.

J'avais trouvé un jour des taux de "buggitude" des différents langages de programmation, par ligne de code, et python était comparativement plus "buggé" mais comme il était beaucoup plus concis, il s'en sortait bien mieux. Ces taux de buggitude étaient par ailleurs assez semblable entre les languages, avec un écart assez faible.

Certe les IDE modernes génèrent automatiquement le "boiler-plate" code pour java … mais ca reste du code à debugguer, et des bugs qui sont cachés dans des volumes plus importants.

Pas mal comme idée … mais si le contact humain est essentiel, commence par ça.

Je m'auto-heberge depuis que je suis plus étudiant (i.e. depuis des lustres) sur des machines de récupération au début. Depuis qu'on est deux, on loue en plus un nom de domaine pour faire sérieux (ou pas) et à force d'être deux, on a fini par être 4 … l'auto-hébergement devient conséquent et maintenant je consens à investir dans du meteriel un peu pro pour pas avoir de problèmes de matériel (qui vit facilement plus de 10 ans).

On a aussi échangé des disques avec d'autres auto-hébergé pour pouvoir faire des backups délocalisé (photo de familles, fiches de paye, impots…), mais c'était "réciproque", i.e. j'héberge le disque du pote qui héberge un de mes disques…

Plus récemment, je me suis à héberger des disques pour des tiers non auto-hébergeurs … et la solution retenue mérite d'être partagée: le tiers passe commande d'une liste de matériel, mais j'ai concoqueté cette liste en particulier les formats de disques (2.5 ou 3.5", interface, …) et j'ajoute ce qu'il faut comme matériel par ailleurs (mémoire, rack, batteries pour l'onduleur). De cette façon, il récupère le disque, où il peut mettre ses données et contribue à la maintenance du serveur. J'ai trouvé la solution élégante et elle me profite aussi un peu.

Dernier point concernant la (sur-) consommation: j'avais évalué que mon serveur coûtait ~50 €/an d'EDF. L'onduleur 500VA donne 12% de charge, ce qui correspondrait à 60W. cela ferait 99€/an … 8€/mois.

Pas vraiment de préférences … j'imprime beaucoup avec le "Dailyfil" de Filimprimante3d, il a l'avantage de pas s'imprimer trop chaud (220~230°). Le "Prusament" s'imprime un peu plus chaud (240-250°) mais toujours avec un super résultat. Le seul avec lequel j'ai eu des problèmes, c'est le "CPE" de Fillamentum qui s'imprime super chaud (275°) et captait beaucoup l'humidité.
Il est bien solide, mais l'humidité fait des bulles, donc l'état de surface est pas terrible (+ risque de bruler le tube en téflon dans le "heat-break").

Je teste bientôt le PCTG, j'espère que ca règle le problème d'adhésion entre les couches. J'ai des clips de sac à dos qui ont cassé à cause de ca, la partie femelle de https://www.thingiverse.com/thing:3943337

Oui, pour les autres, le PLA, c'est l'acide polylactique, facile à imprimer (200°C), il n'a pas besoin de plateau chauffant ni d'enceinte chuffante. Autre point positif: il est bio-sourcé (à base de maïs). Par contre il est rigide, cassant, il se déforme dés 40°. Bref, en dehors de la déco, c'est limité.

J'ai beaucoup d'expérience avec le PET-G, le matériau des bouteilles en plastique. Il s'imprime entre 220 et 300° avec un plateau entre 80 et 100°, sans enceinte. Plus souple que le PLA, donc moins cassant, il résiste jusqu'à 80° voir un peu plus sans se déformer. J'ai accroché des lits au mur avec des pièces en PET-G ! Il y une centaine de kg de charge dessus !

J'ai aussi un peu joué avec le PET-G chargé en fibre de carbone: c'est léger et résistant, super rigide (à en devenir cassant si le remplissage est trop faible).
Par exemple, mon extrudeur/chariot-X de l'imprimante 3d est imprimé avec: 20% plus léger.
S'imprime comme le PET-G, par contre il faut une buse en acier (ou mieux!) car le matériau est abrasif.

Pour les matériaux plus souples, j'ai testé le PLA-souple sans être convaincu et d'autre TPU (Urétane thermoplastique) qui eux donnent de bons résultats. Les materiaux souples sont classés d'après leur dureté Shore avec différentes échelles. Pour le Shore 98A, il doit pouvoir s'imprimer avec un bowden (extrudeur déporté) mais comme tu t'en doutes, j'ai un extrudeur direct et ca s'imprime super facilement. Le défaut du TPU c'est que cela bave beaucoup et qu'il y a beaucoup de "cheveux d'anges". J'ai eu de superbes résultats avec le Filaflex de Recreus 82A: bracelet de montre, tamponoir de porte pour le Ducato, silent-block, coques de téléphones et élastique pour visières anti-covid (et oui!). Le Filaflex est assez technique à imprimer, mais avec un extrudeur direct et double entraînement, ca passe bien (sans le double entraînement, ça bourrait souvent).

Au début, j'ai fait sous-traiter des impressions à un copain qui a une reprap… puis comme cela (lui/nous) prenait pas mal de temps j'ai décidé d'acheter quelque chose qui imprime bien mais qui soit pas prise de tête. On m'a conseillé une Prusa Tcheque: conçue en Europe, open-source, et bidouillable … par contre je voulais une imprimante pour imprimer des pièces fonctionnelles, pas une imprimante pour concevoir des imprimantes3d, ou pour jouer.

J'y ai mis des sous, mais je suis content de l'investissement: aujourd'hui j'imprime majoritairement des pièces pour la maison (bricolage) et pour mon camping-car vieillissant et c'est là que les vrais économie arrivent: Garder un équipement (camping-car 50k€) un an de plus rentabilise à lui tout seul l'imprimante !

Le plus, c'est de pouvoir imprimer des matériaux souples (TPU), des très rigides (fibre de carbone), des légers, des résistants au chaud ou au froid … bref des pièces qui servent dans la vrai vie.

CAO: Freecad, OpenSCAD
Slicer: PrusaSlicer
Imprimante: Prusa i3 Mk2.5s (ca se fait plus, mais on trouve encore les pièces…),

En suivant le lien dans:

On réservera cependant le code source correspondant aux développeurs et aux développeuses aguerris.

Vu dans une conférence sur ce sujet… le scénario le plus pessimiste prévoit quand même une diminution importante des émissions de CO2 à partir de 2050-2060. Pourquoi ? Parce qu'on aura plus de pétrole. LOL (ou pas).

.. le contenu

Par contre, le code ForTran (dans le code source), ça pique toujours autant.

Enfin, Windows il est quand même closed-source, Python non ! Quand tu veux comprendre comment cela fonctionne à l'intérieur, c'est pas la même chose.

Quelqu'un qui se reconnaîtra peut être m'a dit:
"Si ton script bash fait plus de 5 lignes: ré-écrit le en Python"

Et j'en ai écrit des (millions de ?) lignes de Python depuis:
* Scripts en programmation système
* Wrapper en entrée/sortie de programmes Fortan en science.
* Workflow et ordonnancement de programmes
* Métaprogrammation (i.e. manipulation de chaine de caractère)
* Interface vers des programmes plus bas niveau comme le C ou OpenCL.

Finalement il manque les interfaces graphiques, le web et les bases de données, mais je ne pense pas devoir changer de langage de programmation pour ça.

Je me demande si les autres (AMD, ARM, IBM, …) ont mes même problèmes où si c'est Intel qui est particulièrement mauvais (acheté, verolé ?)

Je suis assez d'accord avec ma debian sur un macbook …

Je pense surtout que c'est le modèle de distribution des softs qui a fait la différence.
Il y a anaconda d'un coté, mais aussi et surtout PyPI, wheel, pip et compagnie.

Julia est un langage vraiment cool ! J'adore ce coté Just In Time et j'avais vraiment envie de m'y mettre. Puis j'ai testé numba, et les deux ont le même usage à mes yeux avec les avantages de Python en plus pour numba (et mes 20+ années de pratique).

Salut,

Concernant la création des descripteurs, tu as l'air au point. Ce dont je me souviens (c'était il y a quelques années) c'est qu'après avoir trouvé l'orientation principale du gradient, on fait la même chose sur un voisinage (4x4 si je me souviens bien) avec des histogrammes sur les (8) orientations dans ces voisinages. C'est la dessus que se trouve le brevet je crois (en plus de la DoG).

Le matching est assez simple en fait: il est basé sur norme L1 entre deux descripteurs, cette distance doit être la plus petite possible. L'idée un peu astucieuse est de dire qu'un descripteur A marche avec B d'un l'ensemble de keypoints si C, le deuxième meilleur de cet ensemble match beaucoup moins bien.
soit: dAB < k.dAC avec k=0.53 (0.73*0.73, je sais pas d'où cela viennent ces chiffres).

Je ne penses pas qu'il y ait de brevet non plus sur le matching. Il faut souvent valider le matching par un RANSAC.

Voici une implémentation python (pour référence) du matching.
https://github.com/silx-kit/silx/blob/master/silx/opencl/sift/match.py#L337
Le reste du fichier c'est l'implémentation GPU.

Merci pour la contribution.

J'ai mois même bossé sur une implémentation open-source de SIFT et j'ai pris contact avec les ayant droits: pas de problème à ce que le code soit en licence MIT, les contraintes ne sont que pour les utilisateurs, pas pour le développeur. C'est a dire qu'il suffit pour les utilisateurs de ne pas être sur le sol américain. Et même dans ce cas là, il leur suffit de ne pas "faire d'argent avec" pour ne pas avoir besoin de licence.

Si cela intéresse du monde, le code est ici:
https://github.com/silx-kit/silx/blob/master/doc/source/Tutorials/Sift/sift.ipynb
et je l'utilise pour recaler des time-lap (entre autre).

Je comprends pas trop ton point de vue. La carte Olimex utilise un chip A20 de chez AllWinner avec un GPU Mali400. Ni AllWinner ni le GPU de chez ARM ne sont particulièrement "libre-friendly". J'ai moi même un Pine64 basé sur le A64 du même fabricant avec le même GPU et franchement, les perfs ne sont pas terribles et pour l'instant on est toujours locké sur le kernel d'origine, la procédure de boot est pour le moins obscure … bref je ne n'en suis pas satisfait.

A coté de cela, le Raspberry-pi 3 (et maintenant 2 aussi) utilise un cortex A53, dispose d'une bonne bande passante RAM, le GPU est certes ancien mais les drivers open-sources sont presque finis (en tous cas fonctionnel), le mécanisme de boot est documenté, tout comme le reste de la plate-forme.

Ce serait juste le schéma du PCB de Olimex qui serait libre ? c'est léger comme argument commercial, non ?

A ma connaissance, NUMA a été introduit dans le monde "x86" avec l'Opteron Hammer (dit K8) en 2003 et son contrôleur mémoire intégrée dans le processeur, en mode bi-processeur. En tous cas mon premier système NUMA était une workstation xw9300 de chez HP en 2005. Sur d'autres architectures, je ne sais pas …