[Index Software] Coin des développeurs :]

[Tugdual]

Encore chez Korben :

• Convertir la sortie d’une commande au format JSON ;
• Lien direct...

[Tugdual]

Kathleen Booth, pionnière de l'informatique britannique inventrice du langage assembleur :

• nous a quitté à l'âge de 100 ans...

Extrait :

Kathleen Hylda Valerie Britten est née dans le Worcestershire, en Angleterre, le 9 juillet 1922. Pendant la Seconde Guerre mondiale, elle a étudié à Royal Holloway, Université de Londres, où elle a obtenu un BSc (Bachelor of Science) en mathématiques en 1944. Après avoir obtenu son diplôme, elle est devenue une junior responsable scientifique au Royal Aircraft Establishment, un organisme de recherche à Farnborough. Deux ans plus tard, elle a déménagé au Birkbeck College, d'abord comme assistante de recherche, puis comme chargée de cours puis comme chercheuse.

[...]

En 1950, Kathleen et Andrew se sont mariés, la même année où elle a obtenu un doctorat en mathématiques appliquées, toujours à l'Université de Londres. Pour obtenir un financement supplémentaire pour leur travail, les Booth se sont à nouveau adressés à la Fondation Rockefeller, qui l'a fourni à condition que l'APE (C) X travaille avec les langages humains ainsi que les mathématiques uniquement. Le résultat fut une démonstration de traduction automatique en novembre 1955.

[...]

En plus de construire le matériel des premières machines, elle a écrit tous les logiciels des machines ARC2 et SEC, inventant ainsi ce qu'elle a appelé la Notation Contractuelle. Ce langage, à travers l'évolution et les contributions d'autres, est aujourd'hui connu sous le nom de langage d'assemblage (ou langage assembleur). Elle discute également du fonctionnement synchrone par rapport au fonctionnement asynchrone. Son livre de 1958, Programming for an Automatic Digital Calculator, a été l'un des premiers sur la programmation écrit par une femme. La même année, elle a commencé à travailler avec les réseaux de neurones, également le sujet de son dernier article, Utiliser des réseaux de neurones pour identifier les mammifères marins, co-écrit avec son fils le Dr Ian JM Booth et publié en 1993.

[Bubu]

J'ai résolu le bug du fondu en blanc.
Pour le faire, j'utilise une texture blanche. Un carré blanc.
L'erreur, c'était que je n'utilisais pas le bon thread.
Pour faire des rendus, pour compiler des shaders, pour charger des textures, il faut que ça passe par le thread fournit par OpenGl.

[Tugdual]

Chez Korben :

• FutureCoder – Des cours en ligne gratuits pour apprendre à coder en Python ;
• Lien direct...

[Ancelin]

Pour apprendre à coder, je vous recommande vivement sololearn.
Vraiment chouette comme plateforme.

[Tugdual]

Une avocate spécialisée dans l'open source donne son point de vue :

• sur la plainte contre GitHub Copilot...

[lucius]

Le problème des licences contaminantes est un vrai problème que beaucoup de sociétés se posent. Beaucoup de projets ont échoué car ils n'ont compris trop tard que certaines licences posent problémes et ils ne pouvaient pas faire machine arrière. Le problème est que souvent les chefs de projet en France sont des ingénieurs pas ou mal formés à des problématiques comme la gestion ou le droit (licence, intellectuel, du travail, des contrats...). Cela peut rendre un projet invendable ou non-livrable. La surmultiplication des librairies, des outils annexes (framework, serveur...)... dans les projets pose des soucis. Sans compter que si une seule lib que l'on croyait pouvait utiliser sans souci pour découvrir plus tard que cette lib utilise une autre lib/bout de code à la licence contaminante: Résultat, la crainte d'un effet domino.

Beaucoup d'ingénieurs ne savent pas les différences entre du GPLv2, du GPLv3, du LGPLv2, du LGPLv3, la licence MIT (X11...), EUPL, BSD, boost... et même le Creative Commons (mais là je plaisante... quoique il y a eu du changement). Ils ne sont pas formés à suivre les évolutions des licences.

Pour choisir sa licence, je vous invite à regarder ce site (en anglais)
https://choosealicense.com/

[freeshost]

J'aime bien les licences contaminant les libertés, dont la GNU/GPL.

[lucius]

J'aime bien les licences contaminant les libertés, dont la GNU/GPL.

Sur le papier, cela semble sympa mais je connais des dévs pro open source qui eux-même sont agacés des dérives et de la complexité pour faire des projets car certaines licences sont en conflits entre-elles. Des fois, on ne sait pas qui prime.
Et le pire, c'est lorsqu'un composant change de licence car refait de A à Z, cela peut remettre en question des mois de travail sans que l'on en soit sûr. Un juriste a dit un jour ne pas savoir si une petite framework totalement refaite et qui veut passer de GLPv2 à Apache a le droit.

[freeshost]

Ouais, ça doit être très complexe.

Mais ça peut moins l'être si on est pour le libre partage et usage et modification du code source pour tous.

[lucius]

Sauf que beaucoup des codeurs pro open source travaillent pour des boites qui n'ont pas d’intérêt financiers (et lutter contre la concurrence) que leur code soit accessible à tous et open source. Sans le salaire de ces boites, ces codeurs ne pourraient pas consacrer du temps à créer du code libre. Et on oublie trop souvent l'openwashing.

[freeshost]

Peuvent-ils se tourner vers des licences plus privatrices ?

[lucius]

Transformer une licence comme GNU/GPL vers des licences comme LGPL est plus compliquée.

Par exemple, un projet open source qui devient propriétaire à l'instant T, tout ceux qui ont eu le projet avant l'instant T pourraient théoriquement avoir le droit de changer le code (si GPL).

Si on fait un code qui utilise du code GNU/GPL et du code GNU/LGPL, c'est le GPL qui l'emporte à ma connaissance (sans certitude). Il faut que le propriétaire du code GNU/GPL change son code en LGPL pour éviter les conflits.

Je précise que le GPL n'oblige pas à publier ou fournir le code si c'est à but interne (dans sa boite).

[freeshost]

ll me semble que, indépendamment de la complexité, il y a des choix (pas faciles) à faire.

Après, peut-être peut-on développer des ensembles de licences compatibles (des ensembles plus ou moins libérateurs ou privateurs sur le spectre).

[lucius]

Bon, après, il faut savoir que le GPL n'interdit pas de vendre des exemplaires d'un programme sous GPL à des tiers (logiciel libre ne signifie pas gratuit). Mais le vrai problème est que maintenant, on utilise tant de composants et libs externes même sans le savoir au point que cela devient compliqué de concevoir des projets. résultats, des sociétés préférent utiliser des binaires déjà compilés de programmes GPL car c'est moins contaminant. La liaison d'un projet avec le binaire d'un truc GPL ne le rend pas pour autant GPL à ma connaissance (sauf peut-être certains). Mais il y a aussi un problémes de conflits avec des bibliothèques selon les licences (voir matrice).