Philippe F a écrit 2202 commentaires

Je trouve que ruisseau est bien approprié, au contraire. Avec cette image, je visualise bien la rivière (la connexion principale) et les ruisseaux (des connexions plus petites et rapides) qui en découlent. C'était très élégant comme analogie.

Merci pour cette très belle dépêche et bravo pour le travail de fourmi que vous effectuez. Vous êtes combien pour tester sur autant de configurations différentes ?

En tout cas, ça me rappelle le blog d'Alan Cox il y a 20 ans, qui débuggait du hardware à tour de bras.

Côté LKML, on sent pas trop l'empressement de corriger les problèmes que tu as découvert. Dommage…

Bref c'est quoi les bases à connaître pour être un contributeur valable ?

Tout dépend du projet auquel tu veux contribuer. Une majorité de projets ont aujourd'hui des documentations sur comment contribuer. Tu n'as pas besoin d'être un expert git, GitHub par exemple te mâche pas mal le travail pour proposer une "Pull Request", c'est à dire une contribution. Tu peux suivre un tutoriel et être prêt en 10 minutes concernant la partie git pure.

Un certains nombre de projets ont sous GitHub des demandes d'améliorations ou des bugs marqués "beginner-friendly", c'est à dire accessible facilement aux nouveaux. C'est le bon endroit pour regarder.

Le plus simple est d'identifier un projet en Python qui te plaît, dans ton domaine ou ailleurs et de voir comment il est composé, s'il y a des bugs ouverts, des améliorations demandées ou tout simplement si toi tu vois des problèmes lors de son utilisation.

Si le projet a de l'intégration continue, c'est l'endroit idéal pour voir quels outils sont utilisés par le projet pour sa validation. Il faut chercher dans les fichiers tox.ini , .github, .travis.yml et pyproject.toml. Après, même topo que pour git: inutile de devenir un expert de ces outils, la seule attente finalement est qu'une contribution passe la suite complète de l'intégration continue. Celle-ci sera lancée lors de ta "Pull Request" et tu verras assez facilement ce qui plante, ou tout au moins quel outil a planté. Et tu pourras discuter dans la "Pull Request" avec les développeurs pour recevoir de l'aide.

Le plus simple, c'est finalement de se lancer, et de voir ce qui se passe. Marietta, une des core developpeuse actuelle de Python disait dans une conférence que sa première contribution à Python était la correction d'une virgule mal placée dans la documentation!

Je profite de cette fort belle dépêche sur Flask pour glisser qu'il y a une dépêche en cours de rédaction sur tous les outils d'analyse statique utilisés en Python: black, mypy, flake8, … Si vous voulez apporter votre pierre à l'édifice par vos retours, c'est ici que ça se passe.

On ne peut pas créer un exécutable d'un projet Python.

Ben si pourtant. C'est pas la manière la plus courante de déployer des programmes Python mais ça se fait très bien. Sous Windows, j'utilise pyinstaller qui marche également sous Linux, MacOS, AIX, FreeBSD et Vagrant.

Le déploiement peut péter lors d'un "pip install" parce que pip lui-même

Aujourd'hui, il me semble que ce problème de contrôle du déploiement se résout par un contrôle très figé de tes dépendances. On ne balance pas une mise à jour de ses dépendances en aveugle en production.

Ce problème n'est d'ailleurs pas spécifique à Python, c'est avant tout un problème d'utilisation de dépendances et de contrôle de leur stabilité. Ce problème touche tous les langages qui fournissent facilement des paquets installables, node.js étant bien plus affecté encore que Python. L'absence de vérification de la cohérence des types accentue bien sûr le problème. J'ai espoir que les annotations de type systématiques réduisent une partie de ce problème.

L'écosystème très riche et dynamique de Python permet de démarrer un projet complexes en quelques jours. Mais cela se paie à un moment donné par une exigence de connaissance plus fine sur les dépendances et leurs risques. Comme disent les américains, "un repas gratuit, ça n'existe pas" ("there ain't no free meal").

Certains langages sont très stables, même si leur compilateurs évoluent, même si les librairie évoluent. On peut exécuter un programme écrit il y a plus de 20 ans. Vous vous rendez compte ? (là je pense à Common Lisp)

Ok, il y a eu la transition Python 2 -> Python 3. Mais en dehors de cela, tu as en tête beaucoup de fonctionnalité du langage de Python 3.0 qui ne seraient pas supportées dans Python 3.10 ? Ou de fonctionnalité de Python 1.4 qui ne sont pas supportées par Python 2.7 ? A froid, il n'y a rien qui me vient en tout cas.

La comparaison avec Common Lisp, allons-y: c'est sur que la conception fonctionnelle du langage et des frameworks aident à exclure plein d'erreur qui permettent aux bibliothèques d'évoluer plus sereinement. Mais aussi, on parle d'un langage avec une base d'utilisateurs/développeur très réduite en comparaison de Python. Du coup, c'est sûr que ça évolue moins, et c'est même aussi une des raisons qui font que sa popularité reste faible. Au fait, je fais comment pour faire une interface graphique multi-plateforme moderne en Common Lisp ? En Python, j'utilise PyQt …

Cela dit, je partage une partie de tes critiques, à savoir que Python tout seul, cela ne suffit pas. Il y a un certain nombre de bonnes pratiques qu'il faut acquérir, en particulier s'entourer d'outils externes pour fiabiliser ton code.

Tu pourrais nous refaire des super dépêches sur le travail que tu faisais sur tes jeux ? C'était vraiment passionnant. Ça a abouti à quelque chose ?

Pour rester dans le même filon, mon entreprise vient d'activer une fonctionnalité de sécurité de Office 365 / Outlook 2016 que nous utilisons en interne: tous les mails sont chiffrés. Du coup, je m'suis dit: "cool, plus besoin de chiffrer nos documents en gpg alors !". Que nenni. Il semble que comme l'hébergement soit aux US et qu'on fait globalement de la haute sécurité (carte à puce, passeport, carte d'identité, carte bancaire), on peut pas faire confiance à Crosoft.

Donc on se tape la double couche de documents à échanger en pgp, plus les spécificités de Office pour dire que c'est un mail à usage restreint, niveau de confidentialité "Confidential".

Bill Gates était de ton avis. Une de ses fameuses phrases: "mieux vaut un ordinateur avec un logiciel Microsoft piraté que un ordinateur sans logiciel Microsoft". Je suis pas sûr que Microsoft soit encore en phase avec cette philosophie cela dit :-)

J'avais pas réalisé qu'il y avait en effet un écart de 10 ans entre Bill Gates demandant aux gens d'arrêter d'être des hobbyistes partageurs et RMS qui nous pond la GPL. J'imaginais réellement que les deux évènements étaient contemporains.

Donc RMS a écrit la GPL à un moment où les très gros tel Oracle et Microsoft commençaient à montrer leur puissance. Ça a plus de sens finalement, il a ressenti le besoin de protéger quelque chose qui lui semblait fragile (à juste titre), le libre échange de code. A la même époque, d'autres se sont posés plus ou moins la même question puisque sont nés à quelques années d'intervalle la licence BSD, MIT et GPL.

Cela dit, je reste sur mon point de vue que le monde serait arrivé plus ou moins au même résultat sans la GPL, en choisissant BSD ou MIT, ou encore que quelqu'un d'autre aurait fait une variante de ces licences plus dans l'esprit GPL.

RMS a formalisé quelque chose qui était dans l'ère du temps, mais n'a pas bouleversé l'écosystème du logiciel, libre ou hobbyist de l'époque. Ni d'ailleurs après.

C'est un apport, certes, mais en dehors d'un nombre de cas restreints et documentés (genre busybox), j'ai du mal à croire qu'elle aie changé tant de choses que ça. Une autre licence pouvait aussi faire l'affaire.

Par exemple, la première licence BSD date de 1988, soit la même année que la GPL. La licence MIT est même plus ancienne de quelques années. M. Stallman n'a donc pas été seul à avoir l'idée d'une licence libre (avec moultes définitions possibles de libre, chacun selon ses goûts).

Il faut voir qu'à l'époque où RMS a publié la GPL, tous les développeurs s'échangeaient du code et tout le monde à peu près se foutait de la licence. Ca faisait d'ailleurs râler Bill Gates qui avait besoin qu'on arrête de s'échanger du code librement pour pouvoir vendre le même code!

RMS lui même avait reconnu que la GPL était à la fois une protection pour le logiciel libre et une barrière importante à l'adoption. Ceci était étayé à l'époque par les relations de la FSF avec différentes entreprises qui souhaitaient utiliser du logiciel libre et y renoncaient à cause précisément de la nature de la GPL.

On peut noter que llvm/clang qui utilise une licence très permissive s'en sort tout aussi bien que gcc en terme de popularité. On a pas l'impression que le type de licence freine ou stimule les contributions des développeurs ou des entreprises.

Ca va surement choquer du monde mais je pense que oui, on aurait très bien pu faire sans la GPL et la LGPL et qu'on en serait plus ou moins au même niveau de popularité des logiciels libres aujourd'hui.

En plus, la GPL échoue à garantir au développeur que les modifications de son code faites par d'autres lui revienne. Elle est loin d'être la panacée. Elle ne garantit que le fait que les utilisateurs d'un soft en auront le code source. Du coup, on se retrouve avec un écosystème libre bancal par certains aspects, et des développeurs démotivés par l'exploitation libre et sans contre-partie de leur travaille qu'autorise la GPL.

Aller, pour en remettre une couche: de mon point de vue, GitHub et Sourceforge, ou encore Apache et sendmail ont fait bien plus pour le libre que RMS et la FSF. Ils ont permis au libre de se diffuser massivement, là où la FSF nous fournit toujours un site web digne des années 80.

Sauf que le CEO a le dernier mot en cas de conflit, donc peut imposer une vision technique ou commerciale. Dans toutes les ententes, c'est intéressant de voir ce qui se passe quand ça déraille…

La notion de CEO + CTO d'un côté, et un gérant/commercial de l'autre parait plus adaptée en terme de protection pour le créateur.

Dans les faits, ça marche rarement sur la durée. Il faut vraiment trouver la perle, qui aie envie d'être patron sans pour autant avoir une ego démesuré et vouloir tout diriger. Les cas pratiques que j'ai vu, les "patrons embauchés" se prenaient pour les rois du monde au bout de deux ans et n'hésitaient pas à arrêter le produit et virer le fondateur.

L'idée du retraité est pas mal, il peut effectivement faire ça en dilettante, tout en ayant suffisamment d'expérience pour proposer un accompagnement solide

Je rebondis sur ce commentaire et celui plus haut qui propose de vous associer.

Ca me semble une bonne idée. Sur l'aspect gestion de projet, typiquement, tu peux tout à fait avoir un chef de projet un peu pro dont tu amortis le coût sur plusieurs projets dans plusieurs PME.

Plutôt que de grossir, l'association avec une autre entreprise peut représenter une alternative intéressante: chacune de vos sociétés peut être backup de l'autre. Vous construisez mutuellement un Escrow Agreement qui permettra de rassurer vos client.

Vous pouvez même aller plus loin et mettre vos logiciels dans une sorte de pot commun et vous assurer que vos salariés ont un minimum de connaissance pour intervenir sur les soft de l'autre.

Ca résoud pas les aspects management, mais ça peut déjà simplifier une partie du problème.

Sur l'aspect management, j'aurai tendance à viser une trajectoire différente que celle que tu as prise: retourne en EURL et construis-toi un réseau d'indépendant aptes à intervenir sur ton logiciel, de sorte que tu peux présenter l'équipe logiciel comme l'ensemble des membres du réseau, même si dans les faits, ce sera souvent toi qui fera le job.

Après, il se peut que des grandes structures aient des exigences strictes sur le CA et le niveau de responsabilité d'une entreprise avec laquelle elle travaille. Mais même ça, en lachant de la thune, tu peux te trouver un frontend pour te représenter. Il y a juste le risque très élevé que le frontend te prenne une marge de malade pour ne pas foutre grand chose, voire raconter des conneries au client. Mais bon, à voir ce qui vaut le coup.

Et surtout, c'est exactement ce qu'on attend en général de toi en entreprise : arriver sur une base de code existante de l'entreprise, et s'insérer dedans.

J'ai constaté que mon habitude de lire le code sources des logiciels libres m'a permis d'être assez performant dans mes débuts pour m'approprier la base de code propriétaire de l'entreprise. Un vrai plus par rapport à mes collègues, qui parfois même là depuis plus longtemps que moi, n'osaient pas ou n'avait pas suffisamment l'habitude de le faire pour que ce soit efficace.

Je confirme plus ou moins. Je travaille dans la carte à puce et il est vrai que les produits qu'on livre disposent de la dernière crypto top-moumouthe. Exit le RSA et le DES, vive les ECC et AES. Sauf que … les infrastructures ne suivent pas toujours. Les clients institutionnels sont en général très long à envisager de mettre à jour tous leurs systèmes donc dans les faits, il arrive souvent que de le crypto moins récente que ce qu'on voudrait tous soit utilisée…

En tant que fan de Qt et utilisateur occasionnel de tkinter et utilisateur extrêmement réservé de Gtk, j'étais assez curieux d'aller voir.

En gros, ça permet de construire en peu de lignes de codes des dialogues. Je peux concevoir que se fader la doc Qt ou tkinter juste pour un dialogue de 5 boutons, ce soit très rébarbatif, donc oui, ce projet a un sens.

Pour un dialogue simple, vous aurez surement un résultat en quelques minutes et pour un complexe, en quelques dizaines de minutes. Il faut quand même comprendre la logique de fonctionnement des évènements mais c'est très raisonnable.

Par contre, pour construire une application à proprement dit, je pense qu'il vaut mieux tout de suite passer à la vitesse supérieure avec un toolkit graphique plus élaboré. Le propre des applications graphiques, c'est que si elles répondent bien à un besoin, on leur demande tout plein d'évolutions et on est alors très content d'avoir choisi un toolkit flexible. J'ai encore eu le cas au boulot d'un collègue qui voulait une application très simple pour une démo. Comme la démo a bien marché, il a du faire à vitesse grand V la v2 et autant PySimpleGui aurait pu suffire pour la première, autant pour la version 2, c'était mieux d'avoir un truc un peu plus élaboré.

Je me méfie un petit peu de l'aspect multi-backend. L'expérience de WxWidget, c'est que très vite, on tombe sur des bugs spécifiques à un backend qu'on doit contourner dans le code principal. A voir si ce genre de problème impactera PySimpleGui mais je pense que l'ambition plus modeste que WxWidget pourra lui éviter plus facilement ce genre d'écueil.

En tout cas, le site est soigné, les exemples sont nombreux et clairs, on sent qu'il y a un soin pris pour que ce projet soit une réussite. Bravo à l'auteur!

Pire que le bouton volume qui ne règle plus rien: les plaques à induction. Sur tous les modèles récents que j'ai utilisés, il n'y a que deux boutons -/+ et tu dois sélectionner au préalable sur lequel des 4 feux tu veux régler le niveau de puissance.

Scenario qui m'arrive au moins une fois par mois:
- put*, ca va déborder, faut que je baisse le feu
- bordel de m**, c'est quelle plaque ? Rhaa j'arrive jamais à voir sur leur putain de dessin si c'est celle de droite ou gauche
- ca y est, j'ai selectionné la bonne plaque, je vais pouvoir réduire le feu
- crotte, ça a débordé, l'eau sur la surface des boutons fait que ceux-ci ne fonctionnnent plus donc ça continue à déborder
- ah, en soulevant la casserole, ça arrête de chauffer

Une aberration ces boutons, il faut une licence juste pour pouvoir baisser le feu sous une casserole!

Les autres boutons analogiques qui me manquent: les touches du téléphone. Je me fais pas à ces putains de claviers tactils, je sais jamais si je suis sur la touche que je veux ou légèrement à côté.

Technologie de merde!

Je suis pas encore allé voir la vidéo mais dans mon industrie (la carte à puce), ça fait des années que la conso CPU est utilisé pour attaquer les cartes ou juste savoir ce qu'elles sont en train de faire. Et en général, les pros savent avec la conso exactement ce que le CPU est en train de faire (modification en RAM, chargement NVM, calcul cryptograhpique, etc etc).

Si on commence à se pencher là-dessus côté CPU classique, je suis persuadé que ça va faire très mal.

J'ai un collègue qui voulait quitter la boite et a cessé de venir au travail. Le plus embêté dans ce cas était l'entreprise. Après 6 mois, elle l'a licencié pour faute grave. Et je présume qu'il a touché 6 mois de salaires en attendant. Et il semble que celui lui permette de toucher quand même le chômage (son but au départ).

Finalement, ne pas faire tout dans les règles avec ton employeur peut venir à ton bénéfice.

Je l'utilise déjà pour les dépendances de LuaUnit durant ses tests (luacov en gros). Mais ça m'a demandé de le configurer explicitement.

Par contre, visiblement, un certain nombre de gros projets ayant LuaUnit comme dépendance ne l'utilisent pas. D'où la montée en chiffre artificielle sur LuaRocks.

Concernant le nombre de projet sur GitHub, j'ai éjecté tous les forks en ne comptant que le nom du projet lui-même. Il s'agit bien du nombre de projets uniques utilisant LuaUnit.

En entreprise, on peut en effet gérer un cache entreprise. Et luarocks gère lui-même un cache locale. Par contre, dans une intégration continue Open Source type Travis-CI, il y a très peu de possibilité d'utiliser un cache.

Maintenant que tu as suggéré l'idée, je ne pourrais pas m'endormir sans songer à la façon de faire ce beau graphique et tout le nettoyage qu'il faudra faire sur les données.

Grrr, je n'aurai d'autre choix que de m'y coller un de ces 4.

Perso, pour l'intégration continue, j'utilise travis-ci et AppVeyor qui servent tous les deux des milliers de builds par jour (voire peut-être des millions, il faudrait vérifier). Dès que le build est fini, l'image docker est mise à la poubelle pour démarrer un autre build d'un autre projet.

Donc autant sur mon poste, luarocks pourrait utiliser un cache local ou un proxy, autant sur ce type d'instance partagé, c'est irréaliste.

Par contre, il est possible de configurer travis et AppVeyor pour avoir explicitement un cache de certaines données. Mais cela demande un léger effort, qui ne vaut pas forcément les 5s que tu va gagner sur ton build par rapport à une installation simple.

De plus, certains devops sont attachés à démarrer avec un environnement de build le plus vierge possible et donc n'aiment pas l'effet mémoire introduit avec un cache.

Mais tu as raison sur le gâchis de ressource. Je suis persuadé que tous les gestionnaires de paquets (pip, cargo, npm, luarocks, …) doivent fournir une part très importante de leurs ressources à de la CI qui pourrait les économiser.

Sur mes projets, j'ai fait l'effort en tout cas.

Le script qui relève le nombre de projets n'est pas très fin, il relève juste un nombre. Donc c'est une vision à un instant donné en effet.

Le "churn" est certainement lié à l'ancienne version du script qui comptait le nombre de hit sur LuaUnit et donc notamment plusieurs hits pour plusieurs clones d'un projet. Si certains de ces clones étaient temporaires (le temps que la Pull Request soit acceptée), leur disparition provoque un léger "churn".

Pour la récence, ce serait intéressant en effet. J'y songerai mais je doute que ça fasse un journal intéressant avec cette seule information.