Philippe F a écrit 2214 commentaires

Je me souviens des deux évènements.

Malgré tout le respect qu'on doit à GCC et à Stallman pour avoir démarré ce projet brillant, c'est un projet qui a aussi ses imperfections. M. Stallman n'est pas exempt crises d'égo notamment (arf).

Quand on pense qu'en 2025, il n'a toujours pas digéré que Linux marche mieux que GNU Hurd…

Ce qui est sûr, c'est qu'à l'heure actuelle, on ne peut pas encore faire entièrement confiance à la solidité des algos post-quantiques. D'où la nécessité de prévoir des systèmes de mises à jour dynamique dans nos système. Autant quand on parle de mettre à jour un téléphone ou un PC, c'est assez facile à engager. Quand on parle de mettre à jour sur le terrain un objet aussi sensible qu'une carte à puce, via une infrastructure non maitrisée au moment du déploiement, dans des industries qui fonctionnent encore avec les algo standardisées il y a 30 ans, le défi est autrement plus important.

Mes collègues s'amusent bien réellement. Question pertinente lors de leur dernière démo : on transfert un blob de code chiffré qui va mettre à jour les algos de la carte pour passer par exemple d'un algo classique type ECC à un algo post-quantique. Quel algo utiliser pour chiffrer le blob de la mise à jour de l'algo, tout en restant à l'état de l'art de la sécurité ?

Même si la technologie est encore incertaine, le risque qu'elle fait peser sur la cryprographie est bien réel. Sachant que migrer d'un algo crypto à un autre dans une industrie prend environ une 20aine d'années (et encore, c'est optimiste), c'est bien maintenant que l'industrie de la cryptographie et de la sécurité doit s'en préoccuper.

Ma boite développe de la carte à a puce, et notamment des algo crypto. Pour nous, la nécessité de se prévoir des protections contre cela est indispensable pour avoir quelque chose de nouveau à vendre pour ne pas se retrouver con si la techno se réalise.

Une petite press release qui en parle plutôt pas mal: https://www.idemia.com/fr/perspective/anticiper-les-defis-de-securite-de-lere-post-quantique

Même si la technologie est encore incertaine, le risque qu'elle fait peser sur la cryprographie est bien réel. Sachant que migrer d'un algo crypto à un autre dans une industrie prend environ une 20aine d'années (et encore, c'est optimiste), c'est bien maintenant que l'industrie de la cryptographie et de la sécurité doit s'en préoccuper.

Ma boite développe de la carte à a puce, et notamment des algo crypto. Pour nous, la nécessité de se prévoir des protections contre cela est indispensable pour avoir quelque chose de nouveau à vendre pour ne pas se retrouver con si la techno se réalise.

Une petite press release qui en parle plutôt pas mal: https://www.idemia.com/fr/perspective/anticiper-les-defis-de-securite-de-lere-post-quantique

Tu me fais un choc là. Tout le plan de croissance de ma boîte est basé sur le post quantique. Et celui de nos clients aussi !

Cela dit j'ai soulevé à peu près le même argument en interne, que c'était par la première fois qu'on s'emballait sur une techno et qu'on s'était déjà planté par le passé. Ils m'ont dit: t'inquiète, cette fois ça va le faire!

Autant tout ce que tu dis avant est plein de bon sens, autant je tique sur cette conclusion:

Les conséquences pour la société de refuser le fair-use pour l'entrainement des LLM seraient donc majeures.

A mon avis non. Les conséquences pour la société serait qu'on vivrait comme avant que les IA s'entrainent sur des milliards de documents et on s'en sortait pas trop mal.

Les conséquences sur les boites qui développent de l'IA seraient majeures mais je crois que ça ne m'empêcherai pas de dormir.

En tant que grouillot de fond du couloir, mobilisable à merci, considéré comme trop bête pour remarquer quoi que ce soit d'inhabituel ou trop lâche pour en faire un fromage, Henry a du être témoin durant ces années de petits arrangements avec la loi. Puisque l'heure des comptes a sonné, il est temps de faire un grand travail d'introspection et de mémoire, pour voir si un cadavre ne pourrait pas être déterré et posé sur le bureau du PDG. Ou sur celui de Mediapart.

Si aucun cadavre ne se présente, il reste un plan B: cette boite a forcément des ennemis. Il reste un mois à Henry pour les trouver et leur faire passer quelques petites informations de façon anonyme. Un peu risqué mais tellement bandant ! Rien que d'y penser, Henry se sent mieux. Pour dire, il s'est pas senti aussi bien depuis la fermeture de youporn!

Il faut voir que pas mal de vrais livreurs se comportent exactement comme ça. Ils veulent juste livrer le plus vite possible pour passer à autre chose et en ont rien à foutre de quoi que ce soit… Se présenter, appuyer sur la sonnette, prévenir qu'on va livrer, tout ça, c'est devenu de la fiction. Vive la poste qui reste un brin sérieuse !

Et c'est plutôt bien. Un IDE c'est déjà beaucoup de menus. Si en plus, il y a des menus qui ne servent à rien car pas adapté à ton langage, c'est vraiment bof.

Et les IDE où je te rajoute un plugin vite fait pour rajouter le support Python mais tu sens qu'au final tout est merdique (genre Eclipse), ça donne pas envie de l'utiliser.

JetBrains fournit vraiment des outils de qualités, pensé développeur jusqu'au bout.

Leur vérificateur de type en Python est fait maison et de très bonne qualité. Il popularise largement la notion de vérification de type auprès des développeurs, bien plus que les outils en ligne de commande apportant le même service.

Sachant que c'est quand même un sujet difficile, j'apprécie beaucoup.

PyCharm est vraiment le premier IDE Python qui tient la route que j'ai utilisé. Avant ça, Vim s'en sortait très bien. Depuis, il y a d'autres propositions mais ils ont vraiment ouvert le chemin.

Il me semble que c'est un peu la même histoire côté Java

En effet, skype a changé la donne.

Et je me rappelle avec le sourire que le jour où Microsoft a annoncé le rachat, skype a connu une panne de plus de 3h, fait assez rare même à l'époque…

Rappelez-vous les premiers IPOD fabriqués par Apple. C'était un des premiers appareils fonctionnant au tactil: une molette qu'on pouvait tourner pour zapper rapidement dans une liste de morceaux. Sauf qu'en fait, on ne tournait pas la molette, on faisait glisser son doigt en rond sur une surface tactile avec des bords physiques pour nous aider à guide le doigt. Détail suprême, pour faciliter le retour utilisateur, le bidule émettait un léger clic pour nous aider à comprendre à quel point on avait tourné vite ou pas. Comme sur une vraie molette à cran quoi.

Ce design était très intelligent, tirant partie du tactile (la moitié des gens étaient persuadés de tourner une vraie molette) avec suffisamment de retour physique pour rester profiter de nos immenses capacités de proprioception. Et il restait des vrais boutons, on pouvait appuyer au centre ou aux quatre points cardinaux de la molette pour de vraies actions.

C'était du temps où Apple faisait vraiment des innovations. Malheureusement, cette interface tactile bien pensée a ouvert la voie aux interfaces tactiles minables, aseptisées et réductrices qu'on connait de nos jours.

Aujourd'hui, je défie quiconque de:
- couper le feu rapidement sur une seule plaque d'une plaque à induction
- régler son chauffage en roulant sans quitter les yeux de la route
- éteindre son téléphone sans le sortir de son sac ni le regarder

Lecteur du vendredi, toi aussi, trouve un défi à réaliser avec des vrais boutons, impossible en tactile

Moi je trouve ça insupportable. Ces images de personnages au pseudo-physique de modèle, auxquels je suis censé m'identifier car :
- ils ont adhéré à mon CE et sont heureux en vacances financées par le CE
- ils sont en réunion pro dans une salle avec plus de surface de baie vitrée que ma maison complète, devant une table vide, avec un sourire béat et ils sont en train de réfléchir
- ils ont ont choisi la meilleure assurance familiale et sont en sortie familiale, heureux, bien habillé et coup de bol, il fait un temps magnifique
- …

Cette standardisation de ce à quoi devrait ressembler une vie me fait gerber honnêtement.

Pour l'instant, Multigit a surtout été utilisé par des gens qui souffraient beaucoup du problème qu'il résout, et ont compris tout de suite comment ça marchait.

Mais ta remarque est bonne, un petit guide de démarrage serait le bienvenue. C'est pour ce genre de retour que j'ai posté l'annonce ici.

Je rajouterai ça dans la prochaine version.

Alors, on est d'accord mais j'ai du mal à suivre le fil de ta pensée.

J'explique dans la dépêche qu'on utilise des dépôts séparés pour gérer des droits d'accès car git ne le permet pas au sein d'un repo.

Dans ton premier commentaire tu me dis en gros "sisi, c'est possibles avec des hooks et une branche dédiée".

Ce à quoi je te réponds en gros "non, ou alors je vois pas comment". Et là tu me réponds que "ça sert à rien si on utilise Multigit".

Bref, je saisis pas ce que tu voulais dire dans ton premier commentaire.

Sous git, je ne sais pas comment on peut autoriser la lecture d'un certain répertoire d'un dépôt à une équipe seulement et interdire à toutes les autres personnes d'y accéder. Sachant que ledit répertoire doit rester sous git pour être géré dans le projet comme le reste.

Peux-tu expliciter ta solution ? Pour moi, c'est impossible, git n'a pas été conçu pour interdire des accès à une partie d'un dépôt.

J'accepte les PR !

Mais c'est une bonne remarque, j'avais pas imaginé que ce point ne serait pas clair. Je rajouterai quelque chose dans le README au moins, voire dans un semblant de documentation un jour.

Ok, l'hébergement en Europe sera à part de l'infra US et monde dans ce cas.

Mais les employés de AWS Europe sont bien assujetis via leur maison mère à AWS USA et donc à Trump. Si Trump demande de couper le contact, ils seront devant un conflit moral mais rien ne permet d'être sûr qu'ils choisiront les intérêts de l'Europe plutôt que ceux des Etats-Unis.

Quand je parle de droits d'accès, je parle d'interdiction de lecture. Il ne me semble pas que ta proposition résolve ce problème, j'ai l'impression que tu me parles plus de protected branch.

Surtout que les git hooks, ça doit être installé manuellement pour fonctionner, donc tu n'as pas de garantie que tout le monde aie la même configuration de githook.

C'est possible de définir un "top repo" qui contiendra tous les autres dépôts, y compris par exemple le fichier multigit décrivant la liste de tous les autres dépôts du projet. Ca te donne un workflow un tu clones le top dépôt avec git naturellement, puis tu récupères le fichier multigit pour cloner tous les sous-dépôts.

D'un point de vue multigit pur, il n'y a pas de notion de "top repo", il y a juste un répertoire qui contient un paquet de dépôt multigit avec un niveau d'imbrication quelconque. Notamment, tu peux tout à fait avoir une hiérarchie complexe:

• project directory
  • repo 1
  • subdirectory
    • repo 2
      • subrepo 2.1
      • subrepo 2.2
    • repo 3

Multigit va scanner le répertoire project recursivement pour identifier tous les dépôts git qu'il contient.

Tes dépêches sont toujours un plaisir à lire. Je reste impressionné par la quantité de travail que vous fournissez sur ce jeu et votre attention aux détails!

Oui, l'outil est très orienté "dev au quotidien" et couvre des aspects très pratiques comme créer une branche identique sur 10 dépôts différents répartis au hasard de ta hiérarchie de dépôt.

Il est envisageable de gérer également les sous-modules dans le futur dans Multigit. Voire de permettre la transition entre l'un et l'autre mode. On verra si la demande se concrétise un peu plus.

Je suis pas mal amené ces derniers temps à coder dans des langages où je suis débutant, voire ignare (powershell, C#, groovy). Dès que je comprends rien au langage, je demande à l'ami félin-malodorant. Je pourrais trouver la même réponse soit en lisant une doc spécialisée qu'il me faut d'abord trouver, puis en analysaer mon besoin et la comparant à ce qui est proposé en faisant mon chemin avec l'information que je cherche. Bref, elle fait en 20 secondes ce qu'il me faudrait 5 minutes à faire.

Idem pour des points de documentation précis, elle remplace un bon stackoverflow. Même dans mon domaine d'expertise (Python) où je connais la doc à moitié par cœur et où je suis capable de trouver le chapitre qui m'intéresse en une dizaine de seconde, c'est légèrement plus rapide de demander à l'IA.

Ce qui est proprement flippant, c'est que du coup en tant que débutant, je peux trouver des réponses qui demandent pas mal d'expertise (lire en claire en secure string en powershell). Plus besoin d'être expert pour produire de l'expertise.

L'humain choisissant toujours la voie avec le plus de confort, je me pose la question de qui va encore vouloir devenir expert dans un domaine ? Comment rivaliser avec les faux experts qui résolvent aussi les vrais problèmes. La différence se fera sur les problèmes relativement complexe, où il faut de l'expertise et du recul. Mais si on sollicite un expert, c'est justement qu'on a ni l'un ni l'autre.

Merci, ça fait plaisir de voir que l'outil a un sens dans d'autres organisations que la mienne!

Sur les interdépendances de librairies auxquelles tu dois pas toucher parce que tu risques de casser le projet d'un autre, mais que tu dois quand même modifier parce que t'en a besoin dans ton projet… on a exactement la même.

En théorie, on a résolu ça avec du gitflow, et des branches stables. Sauf que la définition de "stable" est très subjective. Stable, ça veut dire que ça casse pas mon projet. Mais j'ai aucun moyen de savoir si ça a cassé un des deux autres projets qui utilisent la même lib. Les trois projets sont bien sûrs en pression temporelle max, sans aucune marge de manoeuvre pour débugger un truc qui ne concerne pas directement le client.

On a proposé au management de mettre de la CI sur des projets de référence qu'on ne doit jamais casser mais ils ont refusé: ça coût trop cher d'avoir des intégrateurs qui feraient juste ça. Mieux vaut casser les projets de façon aveugle et les réparer à l'arrache, ça marche déjà très bien comme ça.

(je forcis un peu le trait, dans faits, on s'en sort mais il y a toujours un moment où tu es dans une zone aveugle en terme de modifications)

Je dirais pas que ça apporte en plus, c'est une approche différente:

• on continue à utiliser des commandes git contrairement à repo qui utilise une nomenclature différente: sync, upload, … . Pas besoin d'apprendre un nouvel outil et une nouvelle façon de fonctionner

• il y a une interface graphique qui permet de repérer visuellement plus facilement l'état global d'un projet et d'agir facilement sur un sous-ensemble de dépôts

Merci, je trouvais plus le nom de l'autre solution que j'avais regardé. Je l'ai rejetée pour les mêmes raisons, elle introduit de la complexité par rapport aux commandes git classiques et ne permet pas d'interaction graphique simple.

Par contre, l'intérêt des sous-modules, c'est que le commit est ajouté à un commit du dépôt parent comme cela tu garantie que la dépendance est dans la bonne version.

On fonctionne plutôt avec des conventions: l'ensemble des dépôts doit être fonctionnel et stable sur la branche principale (dev chez nous) à sa dernière version. Pour introduire des changements, on va passer par des "features branch" (le git flow quoi) et quand elle est stable, on va merger toute ces branches dans dev. Et au moment où on appuie sur le bouton git push, on publie.

Il y a bien quelques secondes par jour où tu risques de tomber sur une dépendance désynchronisée, mais notre niveau d'activité est suffisamment faible pour que ça n'arrive jamais en pratique. Et même si ça arrivait, tu relances un git pull et tout retombe dans l'ordre.

C'est pas tellement distinct de la façon font fonctionne n'importe quel dépôt git, la branche principale doit être stable