[MIGRÉ] @[email protected]Apr 8, 2017
Hooo, je viens de lire un autre article qui parle de Mastodon, et qui crache dessus par tous les moyens possibles. Cette fois, c’est d’un point de vue technique. Enfin, je crois, l’auteur·ice critique absolument tous les choix techniques (à commencer par les choix de technos, qui seraient « confidentielles » — j’ai peut-être passé trop de temps près de @Keruspe et @clementd mais ruby et node ne méritent pas ce terme — à l’usage de git, qui serait un danger)…
Show thread[MIGRÉ] @[email protected]Apr 8, 2017
(wow, j’ai rempli un toot)
Les arguments sont pathétiques, on sent clairement un·e dev anti-libriste crachant tout ce qu’il peut sur un projet. Ça me fait mal de lire ça en 2017.
Show thread[MIGRÉ] @[email protected]
Pour le lien, c’est https://www.taneleo.fr/reseau-mastodon-un-concentre-de-mauvaises-pratiques
Apr 8, 2017 at 4:57pmWeb
Show thread Software ArchaeologistApr 8, 2017
@gordon mais mais mais c'est encore plus a chier que ton résumé. c'est pas possible c'est de l'ironie hein ? dis moi que c'est une farce
Show threadHobbesApr 8, 2017
@gordon Accuser ruby et nodejs d'être des technologies "confidentielles", c'est effectivement une mauvaise foi éhontée. Ceci dit le coup de cloner un repo git pour faire une installation en production, c'est peut-être pas le plus clean. Après, si c'est un clone d'un tag de release, avec des languages interprétés c'est largement défendable. Je n'ai pas regardé les détails, mais les arguments déployés ne me semblent pas très objectifs.
Show thread[MIGRÉ] @[email protected]Apr 8, 2017
@Hobbes exactement. Ce n’est pas le fait de cloner les sources qui peut être risqué, mais l’absence de workflow clair et de QA sur le projet (compréhensible vu la jeunesse du projet et le fait que Gargron est seul à plein temps dessus)
Show threadHobbesApr 9, 2017
@gordon Clairement, la maturité et le sérieux d'un projet se juge par la gestion des releases, des alertes de sécurité et des bugfixes. Avec des sources en langages interprétés comme ici, faire une install en clonant un repo sur une branche de release "stable", ou installer des paquets natifs, c'est kif-kif (à part la gestion des dépendances sur les autres libs?). Mais au fur et à mesure de la maturité du projet, ne doutons pas que des paquets natifs (.deb, .rpm...) soient créés.