Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Je veux pas faire le mec lourd, mais cette histoire "d'incendie chez moi j'ai tout perdu" serait plutôt un accident de sa part...
https://nypost.com/2020/09/16/reside...rials-charged/
Dans ce cas la, appeler à lui donner des dons parait quand même étrange, si il ne peut pas assurer sa propre sécurité
A moins qu'il y ai un type avec le même nom
Marak, le corrupteur de faker.js et colors.js, affirme qu'il s'agissait d'une erreur de programmation
Marak, l'auteur de la récente corruption du registre de logiciels npm "faker.js" et "colors.js" affirme qu'il s'agissait d'une erreur de programmation
Et souhaite que Github lève son bannissement
L’open source a désormais pénétré la quasi-totalité des domaines de l’informatique. Pourtant, le mouvement continue de traîner l’un de ses principaux maux : la rémunération de ses intervenants. La situation est telle que certains en arrivent à corrompre des bibliothèques largement utilisées pour ne plus avoir à soutenir les entreprises du Fortune 500 de façon gratuite. Quelles leçons la sphère de l’open source doit-elle tirer de la récente corruption des bibliothèques npm faker.js et colors.js ?
La bibliothèque colors a eu plus de 20 millions de téléchargements hebdomadaires uniquement sur npm et compte près de 19 000 projets qui en dépendent. Tandis que, faker a eu plus de 2,8 millions de téléchargements hebdomadaires sur npm et compte plus de 2500 personnes à charge.
Dans l'un des messages du développeur sur GitHub datant de novembre 2020, il déclare qu'il ne veut plus faire de travail gratuit. « Avec tout mon respect, je ne vais plus soutenir les Fortune 500 (et d'autres entreprises de plus petite taille) avec mon travail gratuit. Saisissez cela comme une opportunité de m'envoyer un contrat annuel à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus », disait-il. Marak Squires affirme désormais que la récente corruption du registre de logiciels npm "faker.js" et "colors.js" est la résultante d’une erreur de programmation.
Marak Squires, a introduit un commit (une révision de fichier sur GitHub) dans colours.js qui ajoute un nouveau module de drapeau américain, ainsi que le déploiement de la version 6.6.6 de faker.js, déclenchant la même tournure destructrice des événements. Les versions sabotées amènent les applications à produire à l'infini des lettres et des symboles étranges qui commencent par trois lignes de texte qui se lisent « LIBERTY LIBERTY LIBERTY ».
Marak exprime-t-il tout haut ce que l’ensemble de la communauté open source pense tout bas ?
C’est ce que laisse penser un sondage de Digital Ocean. Ce dernier s’appuie sur les retours de 4440 développeurs participant aux projets open source et issus d’Amérique du Nord, d’Europe et de la région Asie-Pacifique. Plus de la moitié des répondants estiment que les participants devraient être payés pour contribuer aux projets open source (54 %), tandis qu'environ un tiers restent indécis. Seuls 12 % des répondants sont contre le fait de payer les individus pour leurs contributions.
En ce qui concerne la question de savoir qui doit être payé, le rapport met une division entre répondants en lumière. 35 % pensent que les mainteneurs doivent être rémunérés, 30 % préconisent que les contributeurs soient rémunérés et 25 % sont d'avis que les auteurs doivent être rémunérés pour leur travail. Il est intéressant de noter que les jeunes générations sont beaucoup plus favorables au paiement des contributions à l'open source que certains de leurs pairs plus âgés. 60 % des répondants âgés de 18 à 24 ans pensent que les individus devraient être rémunérés pour leurs contributions à l'open source, alors que seulement 53 % des 25 à 34 ans, 51 % des 35 à 44 ans, 42 % des 45 à 54 ans et seulement 34 % des plus de 55 ans sont d'accord.
Les répondants ont également été interrogés sur la question de savoir qui devrait financer ces paiements. Environ la moitié des répondants pensent que les entreprises technologiques devraient financer le paiement des contributions à l'open source, tandis qu'un quart pensent que les propriétaires de projets ou les particuliers devraient payer.
Dans une sphère alimentée par les dons qui permettent de dégager le « salaire » des mainteneurs, Andre Staltz note que « la plupart [80 %] des projets open source considérés comme durables reçoivent en fait un revenu inférieur aux normes de l'industrie ou même inférieur au seuil de pauvreté. » Dans les chiffres, le créateur du réseau social Manyverse passait en revue les 58 projets les plus populaires de la plateforme OpenCollective – un choix qu’il justifie par la disponibilité des données financières des projets qui y sont listés.
Et vous ?
Qu’en pensez-vous ?
Voir aussi :
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
En web, ça prend pas grand temps que si tu mets pas à jour, tu augmentes tes coûts de migration.Envoyé par Waikiki
J'ai eu plusieurs cas avec angular et react
Pour voir ce que c'est, j'ai passé environ une journée à tenter d'installer scala, cette semaine. Je suis horrifié par la pile de dépendances, notamment à Java que ça nécessite. On dépend d'un EDI, forcément, vu la complexité de l'environnement, et le préféré est IntelliJ... Il semble très réputé chez les javaistes, mais quelle usine, aussi !
Pourtant j'ai travaillé dans des environnements multiplateformes, gérant plusieurs architectures de processeurs et versions du système. Jamais vu un beusier pareil.
Bref, plus je vois ces magnifiques outils, ce qu'ils permettent de produire comme daube, plus je me dis que l'informatique compilée à partir de langages adaptés à la tâche avait du bon. Et plus j'évite les machins et les sites qui les utilisent.
Je suis d'accord. Perso, je ne suis pas fan de IntelliJ, vu sa lenteur à la compilation. À part cela, je suis tout à fait d'accord avec vous.
GitHub restaure le compte du développeur qui a intentionnellement corrompu ses bibliothèques
GitHub restaure le compte du développeur qui a intentionnellement corrompu ses bibliothèques,
certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
Marak Squires, l'auteur de deux bibliothèques open source populaires que sont colors.js et faker.js, les a intentionnellement corrompu les deux bibliothèques. La bibliothèque colors a eu plus de 20 millions de téléchargements hebdomadaires uniquement sur npm et compte près de 19 000 projets qui en dépendent. Tandis que, faker a eu plus de 2,8 millions de téléchargements hebdomadaires sur npm et compte plus de 2 500 personnes à charge.
Le développeur de ces deux bibliothèques a introduit un commit (une révision de fichier sur GitHub) dans colours.js qui ajoute un nouveau module de drapeau américain, ainsi que le déploiement de la version 6.6.6 de faker.js, déclenchant la même tournure destructrice des événements. Les versions sabotées amènent les applications à produire à l'infini des lettres et des symboles étranges, commençant par trois lignes de texte qui se lisent « LIBERTY LIBERTY LIBERTY ».
Plus curieusement encore, le fichier Lisez-moi de faker.js a également été remplacé par « Que s'est-il réellement passé avec Aaron Swartz ? » Swartz était un développeur de premier plan qui a aidé à établir Creative Commons, RSS et Reddit. En 2011, Swartz a été accusé d'avoir volé des documents de la base de données académique JSTOR dans le but de les rendre libres d'accès. Militant impliqué dans les grandes causes comme la neutralité du Net, il s’était opposé aux lois SOPA et PIPA (équivalentes de la Hadopi aux Etats-Unis). Aaron Swartz s’est suicidé en janvier 2013. Sujet aux épisodes dépressifs, il était sous le coup d’une procédure légale lourde. Il encourait pas moins de 4 millions de dollars d’amende et 30 ans de prison pour avoir cracké et dérobé 4 millions de documents académiques du MIT et du site Jstor. Un acte réalisé au nom du libre accès à la connaissance.
Dans l'un des messages du développeur sur GitHub datant de novembre 2020, il déclare qu'il ne veut plus faire de travail gratuit. « Avec tout mon respect, je ne vais plus soutenir les Fortune 500 (et d'autres entreprises de plus petite taille) avec mon travail gratuit », disait-il. « Saisissez cela comme une opportunité de m'envoyer un contrat annuel à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus. »
Malgré les ravages provoqués, le symbole du développeur open source modeste se dressant contre les grandes et riches entreprises qui profitaient de lui a énormément résonné dans les discussions sur les forums spécialisés. La réponse à ces actions a elle aussi provoqué un débat.
Il faut dire que suite à la corruption des bibliothèques, Microsoft a rapidement suspendu son accès GitHub et annulé les projets sur npm. Un porte-parole de GitHub a proposé cette déclaration aux actions prises par la structure : « GitHub s'engage à assurer la santé et la sécurité du registre npm. Nous avons supprimé les packages malveillants et suspendu le compte utilisateur conformément à la politique d'utilisation acceptable de npm concernant les logiciels malveillants, comme indiqué dans nos conditions Open Source ».
L'entreprise a également publié l'avis de sécurité suivant : « colors est une bibliothèque permettant d'inclure du texte coloré dans les consoles node.js. Entre le 07 et le 09 janvier 2022, les versions couleurs 1.4.1, 1.4.2 et 1.4.44-liberty-2 ont été publiées incluant du code malveillant qui a provoqué un déni de service en raison d'une boucle infinie. Les logiciels dépendant de ces versions ont connu l'impression de caractères aléatoires sur la console et une boucle infinie entraînant une consommation de ressources système non liée. Les utilisateurs de couleurs s'appuyant sur ces versions spécifiques doivent rétrograder vers la version 1.4.0 ».
Bien que cela puisse être évident pour certains (le développeur a introduit un commit avec du code malveillant et GitHub et npm ont fait ce qu'il fallait pour protéger ses utilisateurs), un débat a éclaté autour des droits d'un développeur à faire ce qu'il souhaite avec son code, quel que soit le nombre de projets et de dépendances qu'il peut avoir.
Par exemple, Angelina Fabbro, directrice de l'ingénierie chez Splice, a noté sur twitter :
« GitHub suspend le compte de quelqu'un pour avoir modifié son propre code dans un projet qu'il possède me fait bien plus peur que NPM qui annule un paquet. J'aime un peu ce que Marak a fait pour se faire entendre et protester.
« Si ces entreprises et leur infrastructure sont si fragiles qu'un ou deux packages qui changent ou disparaissent font des ravages, disons le, leur modèle de risque est nul (c'est en fait le cas de toutes les entreprises technologiques)
« Il y a une chose qui me fait sangloter ET rire… où était l'assurance qualité ? Vous mettez simplement à jour automatiquement les packages et n'exécutez pas de tests de régression avant de publier une nouvelle version de votre logiciel ? C'est gênant ».
Toute suspension semble déraisonnable si vous considérez que le code dans les dépôts appartient à son créateur/mainteneur. Oui, c'est open source en ce sens que vous pouvez le forker et y contribuer, mais cela signifie-t-il que GitHub puisse justifier de vous refuser le droit de modifier ou même de détruire votre propre code ? Y a-t-il une « procédure régulière » dans ce genre de décision ? Y a-t-il un droit d'appel ? GitHub agit en tant que juge, jury et bourreau dans ces affaires et bien que vous puissiez être d'accord avec son action actuelle, qu'en est-il lorsqu'il qu'il se trompe ?
Les autres problèmes soulevés par ces événements sont de savoir comment récompenser de manière adéquate les individus pour le travail qu'ils ont investi dans le logiciel open source qui sous-tend d'autres logiciels plus importants qui permettent aux méga-entreprises de réaliser d'énormes profits. Dans ce cas, ces bibliothèques JavaScript sont utilisées par le kit de développement cloud d'Amazon, qui fait partie d'AWS. Même si colors.js et faker.js bénéficient d'un parrainage qui vise à garantir que les communautés open source soient payées pour le travail qu'elles font, il existe un énorme décalage dans ce que les développeurs qui ont conçu et implémenté des packages populaires comme colors.js et faker. js reçoivent et leur valeur pour les entreprises qui réutilisent leur travail gratuitement.
Le développeur Shirego pour sa part indique : « Je pense, objectivement, qu'ils ne devraient pas faire cela. Même s'il s'agit de projets très importants, ce sont toujours vos projets et c'est finalement à vous de décider ce que vous en faites. GitHub et npm agissant sur les décisions de quelqu'un ne semblent pas cool ».
Brandon Weaver, pour sa part, estime que le débat sur la rémunération des contributeurs de logiciel open source mérite d'être lancé, mais n'approuve pas les méthodes de Marak Squires :
« Maintenant, beaucoup de gens dénoncent GitHub et NPM pour avoir fermé son compte et censuré, ainsi que son discours sur les mainteneurs d'OSS qui ont besoin d'être payés plus au lieu d'être exploités.
« Pour être clair, je suis d'accord avec le point sur OSS, mais je ne suis pas d'accord avec le porte-drapeau ».
Quoiqu'il en soit, le compte de Marak Squires a à nouveau été activé et il a écrit ceci :
« J'ai supprimé le bogue infini de zalgo avec colors v2.2.2 et j'attends des nouvelles du support Github pour récupérer mes droits de publication NPM.
« Aux membres vertueux de la 69e division des médecins des médias sociaux :
« Je vous remercie pour vos pensées et vos prières.
« Je peux vous assurer que je suis sain de corps et d'esprit. J'ai joint un certificat de l'établissement psychiatrique Reid, qui prouve sans l'ombre d'un doute que moi, Marak Squires, je n'ai pas de cerveau d'âne.
« Les membres de la 69e division des médecins des médias sociaux peuvent-ils fournir un document prouvant qu'ils n'ont pas de cerveau d'âne ? »
Risque de dépendance et financement
Armin Ronacher tire la sonnette d'alarme sur les dépendances à outrance, préférées à la place des implémentations internes :
« La bibliothèque colors émet effectivement des codes ANSI pour la colorisation. Une fonctionnalité utile à coup sûr, mais pas révolutionnaire. Je dirais que ce type de fonctionnalité est très souvent mis en œuvre directement au lieu d'en faire une dépendance. Par exemple, lorsque j'ai écrit click, j'ai délibérément décidé d'implémenter la coloration ANSI directement dans ma propre bibliothèque sans dépendre de quelque chose. Mon intuition est qu'il ne faudrait pas longtemps pour arracher et remplacer cette bibliothèque.
« Il y a quelques jours, le développeur derrière cette bibliothèque a décidé de publier une nouvelle version de la bibliothèque qui ne fait plus ce qu'elle annonçait sur la boîte. Comme il s'agissait d'une mise à jour mineure, plusieurs personnes se sont retrouvées avec cette version. Cependant, elles ne savaient même pas qu'elles dépendaient de "ce seul paquet", elles l'ont probablement ajouté parce que quelque chose d'autre dans leur chaîne de dépendance en avait besoin.
« Si vous êtes allé sur le référentiel GitHub de ce développeur, vous avez trouvé deux choses : du contenu complotiste dans le fichier readme du référentiel, mais aussi une justification de la raison pour laquelle sa bibliothèque ne faisait plus ce qu'elle était censée faire : le développeur n'était pas satisfait des entreprises du "fortune 500" qui utilisait son code gratuitement et a demandé un contrat à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus.
« J'aimerais que les gens commencent à discuter de ces choses, notamment du fait que npm (et d'autres gestionnaires de paquets) sont devenus des leviers incroyables. Quelqu'un qui a un forfait avec beaucoup de personnes à charge peut facilement éliminer cette partie de toute l'infrastructure numérique moderne. Daniel Stenberg de curl ne détient pas ce pouvoir (et ne veut probablement pas non plus)
« Le risque que pose une dépendance est élevé avec de petites dépendances plus couramment utilisées, par un seul développeur non vérifié, installées via un gestionnaire de packages comme npm, cargo, pypi ou similaire. Pourtant, quand quelque chose ne marche pas de ce côté, tout le monde s'en aperçoit immédiatement et les gens demandent rapidement des fonds. Pourtant, ce ne sont pas ces dépendances qui soutiennent réellement notre économie. Beaucoup de ces dépendances sont devenues fondamentales, non pas parce qu'elles résolvent un problème difficile, mais parce que nous avons collectivement commencé à adopter la paresse par-dessus tout le reste. Lorsque nous concentrons ensuite nos discussions sur le financement autour de ces types de dépendances, nous détournons implicitement l'attention des packages réellement importants ».
Sources : commentaire de Marak Squires sur GitHub, Armin Ronacher, Brandon Weaver, Shigero, Angelina Fabbro, avis de sécurité GitHub
Et vous ?
Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités
C'est le problème d'utiliser trop de librairies dans un projet. Libre ou Payante d'ailleurs. Au bout de quelques années c'est un vrai calvaire à maintenir.
Mieux vaut se contenter des framework de bases, même si cela limite les choses et ne simplifie pas le travail. Mais au moins on évite les déboires
Après, faut aussi avoir du temps pour le faire.
J'oserais faire le parallèle avec log4J. Avoir besoins de toute une usine à gaz pour tracer l'exécution du code dans un fichier, c'est un peu trop.
Une simple écriture dans un fichier est beaucoup plus simple. Mais moins paramétrable, c'est sure.
Il est surtout temps que les développeurs arrêtent de faire de mise à jour toutes les deux secondes et testent leurs logiciels avant de les diffuser. De VRAI tests.
Pas des tests unitaires à la C qui ne sert à rien, mais de vrais tests fonctionnelles. La aussi, ça prend du temps, je l'accorde. Mais c'est ça faire de la qualité.
Petite anecdote ; je recherchais un logiciel ou un bout de code pour voir les différents droits d'accès sur une collection de projet TFS.
Finalement je trouve un projet sur GIT qui semblait correspondre.
Ne voulant pas tout prendre, je repère dans le code ce qui m’intéresse et le copie dans un projet vierge sous VS.
Malheureusement le projet GIT utilisait une classe externe pour écrire du csv.
Après quelques recherches, je retrouve le package de cette fameuse classe. Et la, je me rend compte que c'est tout un ensemble de merdiers (sûrement très bien) avec tout plein d'abstraction et de codes de réflexion.
Au final j'ai récrit la classe pour écrire le fichier csv. Et ça m'a pris moins de temps que j'avais mis à retrouver le package csv.
En conclusion, je suis assez d'accord avec Armin Ronacher. La plus part des développeurs montent des logiciels sur des bases branlantes, par manque de temps ou tout simplement fainéantise.
Il est temps que cela change et qu'on arrête d'utiliser ces gestionnaires de packages.
Open source
Ce qui est terrible c'est qu'on associe open-source et gratuit.
C'est toujours le cas, ou alors il faut être très précis dans la licence du logiciel. Ou ne pas faire de l'open source, ce qui n'est pas incompatible avec du gratuit (comme le "freeware").
Et va gérer des licences payantes sur du JavaScript...
Faker.js est maintenant un projet contrôlé par la communauté
Faker.js, la bibliothèque intentionnellement corrompue par le développeur, est maintenant un projet contrôlé par la communauté
et son développement sera assuré par une équipe de 8 personnes
Marak Squires, l'auteur principal de Faker.js a corrompu et supprimé la bibliothèque début janvier, mais elle est maintenant de retour sur la toile en tant que projet communautaire. Un référentiel GitHub a été créé pour le nouveau paquet faker.js, et une équipe de huit superviseurs a été constituée pour gérer le projet open source à l'avenir. De plus, un compte Twitter public a également été créé pour communiquer avec la communauté de la bibliothèque JavaScript. Entre-temps, le profil de Squires qui avait apparemment été suspendu par GitHub est à nouveau accessible.
L'on entend souvent dire qu'il est difficile de lever des fonds pour le développement de projets open source au point qu'il est dit que "l'open source est un destin qui ne fait pas de l'argent". Le développeur de la bibliothèque open source faker.js est récemment sorti de ses gonds pour détruire faker.js qu'il avait développée en raison de la difficulté de monétisation. Dans l'un des messages du développeur sur GitHub datant de novembre 2020, il a déclaré qu'il ne veut plus faire de travail gratuit. « Avec tout mon respect, je ne vais plus soutenir les Fortune 500 (et d'autres entreprises de plus petite taille) avec mon travail gratuit », disait-il.
« Saisissez cela comme une opportunité de m'envoyer un contrat annuel à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus ». Il n'a sans doute pas eu une suite favorable à sa demande, ce qui l'a conduit début janvier à corrompre deux des bibliothèques qu'il a lui-même conçues, facker.js et "colors.js", causant de ce fait des dommages à des millions de projets qui en dépendent. Squires a introduit un commit dans colors.js qui ajoute un nouveau module de drapeau américain, ainsi que le déploiement de la version 6.6.6 de faker.js, déclenchant la même tournure destructrice des événements.
Les versions sabotées amènent les applications à produire à l'infini des lettres et des symboles étranges, commençant par trois lignes de texte qui se lisent « LIBERTY LIBERTY LIBERTY ». Les utilisateurs ont bien évidemment compris que les bibliothèques venaient d'être compromises, mais étaient loin de s'imaginer que la personne à l'origine de la compromission est Squires lui-même. Il a bloqué des milliers de projets. Pour vous donner une idée de l'ampleur des dégâts, la bibliothèque colors.js a eu plus de 20 millions de téléchargements hebdomadaires uniquement sur npm et il y aurait près de 19 000 projets qui en dépendent.
De son côté, faker.js a eu plus de 2,8 millions de téléchargements hebdomadaires sur npm et plus de 2 500 utilisateurs. En réponse au geste de Squires, faker.js a été transformé en projet communautaire. Les tentatives pour le faire ont commencé. Facker.js, qui n'a existé que sur GitHub jusqu'à sa suppression par Squires au début du mois, a à présent un site Web selon lequel le développement de la bibliothèque sera maintenant assuré par une nouvelle équipe de huit personnes. Sur le site Web, il est également fait référence à la suppression par Squires. Selon la nouvelle équipe, "Squires a joué un mauvais tour à la communauté".
« Le projet Faker était géré par Marak Squires, un passionné de Node et un professionnel qui s'est mis en colère et a agi de manière malveillante le 4 janvier 2022. Le package a été supprimé et le projet a été abandonné. Nous avons maintenant transformé Faker en un projet contrôlé par la communauté, actuellement géré par huit ingénieurs issus de divers horizons et entreprises », indique le tout nouveau site Web de faker.js. Squires n'a pas commenté ces déclarations sur Twitter. Il a annoncé avoir corrigé le bogue Zaglo dans la bibliothèque JavaScript colors.js, mais ne pas avoir pu le télécharger sur le gestionnaire de paquets npm.
Depuis la suppression de faker.js début janvier 2022, la communauté et d'autres programmeurs intéressés discutent activement du sujet. Certains utilisateurs montrent d'une part de la compréhension pour l'action de Squires, qui a supprimé faker.js, mais ils continuent d'exprimer leur mécontentement face à cette action. En effet, malgré les ravages provoqués, le symbole du développeur open source modeste se dressant contre les grandes et riches entreprises qui profitaient de lui a énormément résonné dans les discussions sur les forums spécialisés. En outre, le rôle de GitHub dans cette affaire est également remis en question.
Certains ne sont pas d'accord avec le Fait que GitHub ait bloqué le compte de Squires. Par exemple, Angelina Fabbro, directrice de l'ingénierie chez Splice, a déclaré sur Twitter : « GitHub suspend le compte de quelqu'un pour avoir modifié son propre code dans un projet qu'il possède me fait bien plus peur que npm qui annule un paquet. J'aime un peu ce que Marak a fait pour se faire entendre et protester. Si ces entreprises et leur infrastructure sont si fragiles qu'un ou deux packages qui changent ou disparaissent font des ravages, disons-le, leur modèle de risque est nul (c'est en fait le cas de toutes les entreprises technologiques) ».
« Il y a une chose qui me fait sangloter et rire. Où était l'assurance qualité ? Vous mettez simplement à jour automatiquement les packages et n'exécutez pas de tests de régression avant de publier une nouvelle version de votre logiciel ? C'est gênant », a-t-elle ajouté. Plusieurs personnes ont estimé que la suspension du compte de Squires était déraisonnable puisqu'il s'agissait de son propre code. GitHub a décidé plus tard de restaurer le compte de Squires, qui semble désormais être accessible. Quoi qu'il en soit, le comportement de Squires a à nouveau soulevé la question de la "surdépendance" des projets vis-à-vis des bibliothèques tierces.
Source : Faker.js
Et vous ?
Voir aussi
Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités
Il y'a eu autant d'applis que ca impactées en prod ? Si c'est le cas c'est effectivement inquiétant. Ca veux dire que c'est déployé avec 0 test.Par exemple, Angelina Fabbro, directrice de l'ingénierie chez Splice, a déclaré sur Twitter : « GitHub suspend le compte de quelqu'un pour avoir modifié son propre code dans un projet qu'il possède me fait bien plus peur que npm qui annule un paquet. J'aime un peu ce que Marak a fait pour se faire entendre et protester. Si ces entreprises et leur infrastructure sont si fragiles qu'un ou deux packages qui changent ou disparaissent font des ravages, disons-le, leur modèle de risque est nul (c'est en fait le cas de toutes les entreprises technologiques) ».
Par contre sur des projets js d'envergure , bien malin celui qui est capable de maitriser son arbre de dépendances à 100% . Sur le premier niveau oui évidemment , ensuite ca devient très vite très compliqué. C'est le revers de la médaille d'avoir une gestionnaire de dépendances très efficace malheureusement.
Je ne sais pas si ca existe sur les gestionnaire de dépendances, mais il faudrait pouvoir mettre une limite (surchargable) sur le nombre de dépendances en cascade pour avoir conscience que l'import de truc va appelle bidule qui lui meme appel machin1 , machin2.
Alors je pense que ça dépend des gestionnaires mais quand tu analyses la qualité de ton code, tu peux/devrais aussi analyser ton arbre de dépendances. Tu as des outils pour ça, y compris des outils de visualisation.
C'était son projet et sa bibliothèque.
Il est encore libre de faire ce qu'il veut avec et tout supprimer si cela lui chante.....
Aaaaah, le complotisme. Le truc pour décrédibiliser n'importe quels propos. Le gars est encore libre de penser ce qu'il veut, et peut-être que son affirmation sur la mort de Aaron Swartz n'est pas à prendre au sens littéral (je ne suis pas dans sa tête).
Tout à fait. On ne devrait tirer des dépendances externes que lorsqu'elles sont nécessaires. Après, le problème qui se pose ici est celui des dépendances transitives.
Ou alors, dans le cas de Log4J apprendre que SLF4J, une API de log compatible avec la plupart des frameworks de log Java (dont Log4J), est disponible depuis au moins 2006, et que c'est idiot d'avoir du code qui dépende d'implémentations plutôt que d'abstractions, surtout quand on sait que chaque projet/framework/serveur peut tirer son implémentation.
Là encore, ça dépend de la façon dont le projet est architecturé. C'est sûr que si on a un patchwork de CRUD ou de la SPA sans aucune gestion d'états, l'écriture et surtout la maintenance de tests automatisés devient très compliquée, ce qui laisse peu de temps pour automatiser des tests UI par exemple.
Eh bien ça dépend. Un gestionnaire de packages, ça permet de gérer les dépendances, y compris sur vos projets en interne, ce qui est formidable. Le problème c'est plutôt le patchwork de bibliothèques en dépendances directes/transitives, et là on en revient au point écrit plus haut, de n'embarquer les choses que quand elles sont nécessaires.
Tout à fait. Mais visiblement Github n'est pas d'accord avec ça et se torche complètement avec la licence déclarée sur notre code.
Une façon respectueuse de la licence aurait été de forker le projet, de le publier comme fork, et de demander à tous ceux qui ont automatiquement tiré la dernière version du paquet (mauvaise pratique) de remplacer leurs dépendances.
Tout à fait ça reste SA propriété intéllectuelle
Je ne comprends pas trop, n'avons nous pas eu droit la semaine dernière a une floppée d'article indiquant qu'il avait été débanni ?
A la base, c'est son projet, il est donc sencé pouvoir en faire ce qu'il veut, je ne comprends pas pourquoi il est banni par github.
Autant des projets open source qui marchent peuvent être une super vitrine quand on cherche du boulot , autant là il s'est auto catalogué comme saboteur professionnel. Je lui souhaite de pas avoir à chercher du travail dans les quelques années à venir.
S'il voulait absolument de l'argent pour son travail open source, pourquoi ne pas avoir essayé d'en soulever avec par exemple OpenCollective ou tout simplement arrêter de contribuer ? Au lieu de ca, il sabote ses projets et feint l'ignorance... Et pour ce qui est de l'argument "ce sont ses projects, il fait ce qu'il veut avec", oui forcément il a les droits admins donc il peut faire ce qu'il veut. Sauf qu'il sabote le travail des autres contributeurs (quand il y en a) et la réputation de l'open source en général. Et continuer a prétendre que c'était une erreur alors qu'il l'a clairement fait exprès, c'est pas très classe...
Oui parce que ce gros boulet de base, après avoir été débanni, a récidivé.
Du coup, il a été rebanni et je pense que cette fois-ci il devra passer sous le bureau pour espérer retrouver l'accès à son compte.
De plus, prétendre une "erreur de programmation" c'est vraiment du foutage de G. Il n'a même pas honte ? Il mérite la corde.
Répondre avec citation
Partager