Il était une fois 11 lignes de code qui vivait dans un module npm appelé left-pad :
module.exports = leftpad;
function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}Ce module a été écrit par Azer Koçulu et est utilisé indirectement par des projets connus comme ember, babel et react-native. Il se trouve que l'auteur a également écrit d'autres modules pour npm dont l'un, kik, lui a valu des ennuis avec une société du même nom. Kik.com a d'abord demandé à ce que le module soit renommé et, suite au refus de l'auteur, s'est tourné vers npm.com pour faire retirer le module de npm (violation de copyright).
Npm a donné raison à kik.com et Azer Koçulu s'est fâché tout rouge. Pour lui, npm est un terrain privé sur lequel les entreprises ont plus de pouvoir que les humains et ça va à l'encontre de sa vision de l'open-source (Power To The People). Du coup, il a décidé de dépublier tous les paquets npm à son nom. Et ce fût le drame.
La dépublication du module left-pad a entraîné l'échec du build de nombreux projets open-source. Un mainteneur a repris le module et a publié une nouvelle version sur npm. Mais cela n'a pas suffit à corriger le build de beaucoup de projets qui dépendaient d'une version spécifique de left-pad. Du coup, le nouveau mainteneur a demandé à npm de republié la version dépublié, ce qui a été fait même si les avis au sein de l'organisation npm sont partagés. Le CTO de npm le dit lui-même : cette action est dans une zone grise d'un point de vue légal. Rien dans les TOS de npm ne parlent de ce cas de figure (la republication d'un module npm).
On peut lire ici les explications d'Azer Koçulu : I’ve Just Liberated My Modules, et là les tweets du CTO de npm : https://twitter.com/seldo/status/712414400808755200.
Plus largement, on peut se poser la question de la fiabilité des projets JavaScript qui dépendent de centaines de modules npm. Vu le nombre de modules, il faut s'attendre à des problèmes et donc prévoir des solutions. Comment gérer un module dépublié ? Et si un module venait à avoir une faille de sécurité ?
Certains proposent de redécouvrir le linkage statique, d'autres mettent en avant leur outil de packaging, pourtant beaucoup plus jeune mais déjà mieux pensé.
Et pour conclure, voici le tweet de Brad Fitzpatrick :
lol npm
# ça se serait passer comment avec une distribution linux style debian ?
Posté par Tangi Colin . Évalué à 4.
Tout est dans le titre, je sais qu'il y a plus d'un mainteneur debian qui moule sur linuxfr, ça serait intéressant de savoir comment debian gère ce cas de figure.
[^] # Re: ça se serait passer comment avec une distribution linux style debian ?
Posté par Framasky (site web personnel) . Évalué à 10.
Je pense que le problème vient plus de npm : c'est une entreprise. Je pense qu'une structure comme l'asso Debian ou le Perl NOC pour le CPAN (je ne connais pas le statut de ceux qui gère pypi ou les dépôts des gems Ruby) n'aurait pas supprimé le module suite à une simple menace, ils auraient creusé, contacté le développeur, etc.
Enfin, c'est mon ressenti, je me trompe peut-être.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: ça se serait passer comment avec une distribution linux style debian ?
Posté par Tonton Benoit . Évalué à 10.
Ben justement Debian a des mainteneurs et ne publie que des logiciels libres, la licence permet de continuer à distribuer le logiciel même si l'auteur fait un caca nerveux.
Là si on voulait faire un parallèle c'est plutôt comme un systeme de build qui récupère directement ses dépendances sur github, il suffit qu'un dépôt forme ou change de nom pour que ça ne marche plus.
[^] # Re: ça se serait passer comment avec une distribution linux style debian ?
Posté par Aissen . Évalué à 4.
Là on parle de la marque qui voulait récupérer le nom du paquet npm "kik", pas simplement de logiciels libres (tous sont sous licence libre.)
[^] # Re: ça se serait passer comment avec une distribution linux style debian ?
Posté par flan (site web personnel) . Évalué à 6.
Avec Debian, tu peux fournir un paquet différent mais qui remplit exactement le même rôle.
Par exemple, tu peux avoir "JVM" en dépendance, et cette dépendance peut aussi bien être fournie par la JVM d'Oracle qu'OpenJDK (oui, je sais, c'est plus ou moins la même chose maintenant) ou toute autre JVM.
[^] # Re: ça se serait passer comment avec une distribution linux style debian ?
Posté par scullder . Évalué à 8. Dernière modification le 25 mars 2016 à 11:30.
Les distributions linux n'arrivent pas à suivre le dependency hell de beaucoup de projets qui utilisent extensivement rubygems, PyPI, npm, etc.
Par exemple, sous archlinux, on ne peut pas installer plusieurs versions d'un même paquet.
Donc on doit créer un paquet différent par version pour le même module.
Comme beaucoup de modules ont des cycles de développement pas très carrés et ultra rapides et cassent régulièrement leur rétro-compatibilité, ça devient vite compliqué et contre productif de repackager 10 versions différentes de chaque gems de rubygems… A mon avis, ça demande énormément de travail de packaging pour des avantages relativement faibles…
Au final, tout le monde utilise des hacks comme rvm et installent tout dans leur homedir car c'est impossible d'utiliser ruby sans cloisoner chaque projet ruby dans un gemset indépendant…
Après si on ne se pose plus la question de la pérénité des dépendances, j'ai envie de dire qu'on l'a bien cherché… Peut-être qu'on ne devrait pas dépendre sur des dizaines de modules aléatoires publiés par des inconnus qui n'ont aucune intention de les maintenir à long terme…
edit: en fait, j'ai mal compris la question et je n'y réponds pas exactement…
# Trollons
Posté par MTux . Évalué à 10.
C'est justement ça qui me fait détester npm et node en général.
Rien n'est jamais packagé (par la distribution) dans la bonne version, il faut donc compiler et installer des milliards de dépendances et ce système est bancal. Tellement bancal qu'on en vient à utiliser Docker comme cache-misère.
En tant que sysadmin je ne veux pas de node chez moi.
[^] # Re: Trollons
Posté par barmic . Évalué à 7.
Quelle est la différence avec cpan par exemple ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par MTux . Évalué à 8.
Je n'en veux pas non plus.
Pareil pour pecl.
Si la dépendance n'est pas packagée dans la distribution, l'appli va à la poubelle.
[^] # Re: Trollons
Posté par raum_schiff . Évalué à 4.
Jusqu'à ce que le paquet devienne obsolète / non maintenu …
En ces temps hystériques, c'est dur de trouver du code stable mon bon monsieur !
[^] # Re: Trollons
Posté par MTux . Évalué à 4.
Sur Debian les paquets sont maintenus très longtemps.
Alternativement il y a FreeBSD et ses ports (à compiler ou à récupérer directement sous forme binaire) qui propose différentes versions d'un même logiciel (par exemple il y a php5.5, php5.6 et php7, avec les dépendances en option).
[^] # Re: Trollons
Posté par barmic . Évalué à 10.
Non, 5 ans c'est bien, mais ce n'est pas « très longtemps ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Adrien . Évalué à 2.
C'est comme tout, à un moment il faut bien mettre des moyens. En l'occurence il existe des sociétés qui proposent des prestations pour faire du packaging Debian.
[^] # Re: Trollons
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
D'abord, sur le CPAN, il y a une hiérarchie de nom et donc se construit un système de nom de manière collaborative. Il n'y a pas 15000 modules à plat. Ensuite, sur le CPAN, il y a tous les sources avec toutes les versions. On ne va pas chercher à droite et à gauche. La licence est toujours une licence libre. La règle est que le premier qui se sers du nom a le nom, mais tout le monde peut proposer un module dans cet espace de nom.
Bref, CPAN n'est pas qu'un annuaire…
[^] # Re: Trollons
Posté par barmic . Évalué à 3.
Je répondais à ça :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Désolé pour le bruit.
[^] # Re: Trollons
Posté par Michaël (site web personnel) . Évalué à 8.
C'est pourtant évident: JavaScript est une technologie maudite par des années d'utilisation par des web-developpers pour faire du front-end et qui n'a rien à faire dans l'horizon d'un sysadmin digne de ce nom, tandis que Perl, c'est le bien, la lumière, et la vraie philosophie Unix. Une bonne vieille querelle de clocher, en somme. – Je sais que tout le monde sait, mais le titre du fil est “trollons” ;)
[^] # Re: Trollons
Posté par barmic . Évalué à 10.
Ce que je trouve marrant avec certains sysadmin, c'est comment ils priorisent l'esthétisme de leur système au fait qu'elle servent à quelque chose :)
Si ce n'est pas packagé (et que tu veux à tout prix passer par là) tu peux packager toi-même (ça ne doit pas être si dur si tu le demande à tout le monde) soit demander à packager.
Le boulot du sysadmin c'est d'avoir un système propre ou de fournir des services aux utilisateurs ?
Moi en tant que dev, je suis pas fan de js, mais comme je veux avoir une IHM web qui soit un peu réactive (pas de rechargement complet à tous les cliques), j'utilise js. Je vois pas à quoi ça sert de rester camper sur des paradigmes « j'aime pas donc je boude ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par MTux . Évalué à 10. Dernière modification le 23 mars 2016 à 15:00.
Simplement parce que le sysadmin c'est lui qui se tape les install, les upgrades, les migration et pas le développeur. Si tout est packagé proprement un dpkg -l suffit à voir ce qui est installé sur ta bécane. Si en revanche s'il faut inspecter dpkg, cpan, pecl, npm, en notant les versions particulières ça devient l'enfer. Avoir un serveur propre c'est le boulot du sysadmin.
Autre exemple : en cas de maj du kernel ou de libc6, si cela impacte des paquets ils seront mis à jour eux aussi. Par contre tes bidules npm non, c'est à toi de savoir que ça va merder et qu'il faut recompiler.
[^] # Re: Trollons
Posté par flagos . Évalué à -7.
Et pourquoi dpkg est plus "propre" que les autres ?
Tu fais quand même pas ça a la main ? T'as pas un stagiaire pour te scripter ça ?
[^] # Re: Trollons
Posté par Spack . Évalué à 8.
D'autant que ce n'est pas très compliqué.
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Il y a des paquets npm qui nécessitent une compilation ?
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
hoooo oui, malheureusement.
bcrypt par exemple.
[^] # Re: Trollons
Posté par barmic . Évalué à 10.
Quelque soit le système de packaging, « si tout est packagé proprement », généralement ça reste propre ;-)
Les développeurs ne testent pas ça ? Genre ils codent et commit sans jamais rien exécuté et toi tu dois inventer les procédures d'install/update/migration ? :)
C'est le développeur qui indique les versions de ce qu'il utilise.
Non, avoir un serveur propre c'est trivial et à la porté du premier venu. Tu télécharge l'iso de l'OS que tu veux, tu l'installe, tu débranche le câble réseau : t'as un serveur propre.
Le boulot d'un sysadmin (ou d'un devops) c'est de maintenir un serveur qui fournis les services qu'on lui demande et oui ça demande de faire avec les services qu'on lui demande et oui il y a des fois où tu ne va pas pouvoir t'appuyer sur le travail de ta distrib (parce qu'il existe autre chose que SSH/(S)FTP/SMTP). Et oui ça demande de faire autre chose que juste la commande sortie de la doc de ta distrib'
Par contre t'es ultra outillé pour le faire quand même entre chef, puppet, ansible, salt, fabric et tout ce qui vient avec la mouvance des plateformes immutables (docker entre autre).
Donc oui c'est du travail, sinon ce ne serait pas payé ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par morphalus . Évalué à -2.
Toi, tu es soit un développeur pensant connaître le métier de sysadmin/devops, soit ça ne bouge pas beaucoup chez toi.
[^] # Re: Trollons
Posté par barmic . Évalué à 9.
Tu n'avais rien de plus méchant en stock ?
^_^Ou alors fouiller un peu le web pour chercher des casseroles.
J'ai pas compris, le « ça ne bouge pas beaucoup chez toi », mais maintenir une intégration continue avec installation de la version N, mise à jour vers la version de dev, passage des tests, puis passages des tests de charge (tout en sachant que ce n'est pas ton boulot, c'est rarement chiffré, c'est sensé être lissé dans ton travail quotidien). Ce n'est clairement pas identique au boulot du sysadmin (et ça ne prévient pas forcément des problèmes que peux rencontrer le sysadmin), mais affirmer que les dev n'ont aucune conscience des problématiques d'admin, c'est juste drôle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par totof2000 . Évalué à 4.
donc c'est plus grave alors : ils en ont conscience mais ils s'en fichent royalement !!! Merci pour m'avoir donné un prétexte pour leur taper dessus.
[^] # Re: Trollons
Posté par benja . Évalué à 3.
Il te visait personnellement, enfin bon libre à toi de généraliser.
Ceci dit, pour en revenir à nos moutons, j'ai l'impression que tu n'as pas compris la différence entre "version X fonctionne avec mon code" et "la version X est maintenue et fonctionne sur mon système". Par exemple dans le cas de debian, tu as de nombreux logiciels en version X qui ne correspondent pas à la version X de upstream car ils contiennent des corrections supplémentaires. C'est à dire que le sysadmin doit s'assurer non seulement que le logiciel fonctionne en tant que tel, mais aussi en temps que composant d'un système. Alors, à moins de nous avouer que tu développes directement sur la prod en tout bon rambo qui se respecte, j'estime que tu n'a pas prouvé ta légitimité pour pouvoir discréditer les sysadmins… ;-)
[^] # Re: Trollons
Posté par benja . Évalué à 1.
s/temps/tant;s/ à d/-à-d/
[^] # Re: Trollons
Posté par Guillaume Rossignol . Évalué à 3.
Fournir le service (au client donc) est indépendant de la «tambouille» interne dev/admin pour savoir qui doit se taper le boulot. Parce qu'on peut tres bien prendre le même raisonnement, dire que le boulot de dev, c'est de fournir un code qui marche en respectant les contraintes de libs et que du coup, c'est à lui de se demerder avec la version packagé de la lib (celle qui est testé par les packageurs, dont on sait qu'elle va avoir les patchs de sécurité) plutôt que celle fraichement tagguée sur github (celle où la retro-comptabilité a été cassée sans faire expres, dont la conf par défaut à changé dont…).
La question est donc : qu'est ce qui nous coute le plus cher, qu'est ce qui est le plus pérenne. Si tous tes services sont déjà dockerisé, chaque appli tourne avec la version qu'il lui faut, effectivement, c'est simple. Sinon, ca peut etre vachement compliqué et risqué de faire tourner plein de fois la meme lib à des versions différentes.
Parfois, on peut oublier qu'il n'y a pas que l'appli sur laquelle on est en train de bosser qui tourne sur la machine, mal mesurer un effet de bord etc. Le «Je comprend pas pourquoi les tests passent pas sur la plateforme de tests, en local ils marchent très bien» ça m'est arrivé, ainsi qu'aux collégues une paire de fois.
[^] # Re: Trollons
Posté par barmic . Évalué à 7. Dernière modification le 23 mars 2016 à 17:28.
C'est souvent le cas et ça ne me choque pas tant qu'il s'agit de gérer les mises à jour du système et pas de figer le système (et donc de se garder un truc plus maintenu pendant des années).
Pour le reste, je suis d'accord. Ce que je veux dire, c'est que l'image du pauvre sysadmin qui se fait malmener par les méchants dev qui font n'importe quoi sans avoir la moindre idée de ce qu'est ou ce que fait un sysadmin, c'est un peu surfait.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Christophe B. (site web personnel) . Évalué à 3.
Ah bon ? tu parles peut être de VRAI dev, car j'en connais beaucoup qui font semblant …
Et je parle pas des dev qui oublie les 2 principes de bases : Fréquence et Volume
Ou ceux qui vont modifier DIRECTEMENT dans la version en exploitation.
Les tests c'est comme les freins sur les voitures c'est pour les lâches …
Je caricature un peu … mais pas beaucoup
[^] # Re: Trollons
Posté par totof2000 . Évalué à 4.
tu me rassures, je commencais à croire que j'étais le seul à bosser avec ce genre de dev.
[^] # Re: Trollons
Posté par MTux . Évalué à 10.
A la différence que c'est mieux d'avoir 1 unique système de packaging plutôt que d'en gérer plusieurs qui sont en conflit entre eux.
Je ne met pas en conflit les sysadmin et les développeurs, je dis simplement que les deux ont des contraintes différentes. Un environnement de dev et de production c'est différent. Tu peux concevoir ton application de la meilleure manière possible, il y aura toujours potentiellement des problèmes en production car elle doit cohabiter avec d'autres, être soumise à des contraintes de sécurité (parefeu, selinux), de haute disponibilité, etc.
Voilà pourquoi je n'aime pas les écosystèmes exotiques qui font cavalier seul, avec leurs propres dépendances, au lieu de se baser sur ce qui existe et ce qui est stable.
Non. Ça c'est l'informatique des années 90 et on en paye le prix aujourd'hui (dette technique). Des choses installées sur le tas, non documentées, non pensées et sans visibilité sur l'avenir. Un bon sysadmin c'est quelqu'un qui a de l'expérience et connaît les choses à faire et à ne pas faire. Et accessoirement c'est lui qui se fait réveiller à 4h du matin quand la prod crashe, pas le développeur ;)
Oui, le sysadmin est le chef d'orchestre de l'infrastructure. Mais cela va plus loin que ça, par exemple installer un serveur Apache peut paraître simple (apt-get install apache2), mais ça ne l'est pas si on veut faire ça proprement (écriture de vhost de manière propre et sécurisée, dimensionnement, documentation, perspectives d'évolution…).
Oui, ce sont des outils formidables si bien utilisés.
Mais par exemple je ne laisserai pas Ansible mettre à jour libc6 si je sais que le serveur a des logiciels custom compilés à la main, trop dangereux.
Pas assez malheureusement…
[^] # Re: Trollons
Posté par gregR ☯ (site web personnel) . Évalué à 1.
Mais pourquoi ?… Pourquoi on ne peut pertinenter plusieurs fois ? :'(
http://gregr.fr
[^] # Re: Trollons
Posté par gnumdk (site web personnel) . Évalué à 3.
Si tu vas par là, un bon sysadmin il a:
- Une documentation complète des projets
- Une documentation complète des serveurs
Sur une version stable de ta distro, tu n'auras pas d'upgrade de libc6 qui va casser tes propres builds.
Si tu fais une mise à jour de ta distro vers une nouvelle version majeur, dans le monde du travail(je ne parle pas d'administrer son serveur perso), tu fais au minimum une préproduction (et mieux une qualification).
Tu ne fais pas un dist-upgrade sur un serveur de prod comme un porc.
[^] # Re: Trollons
Posté par totof2000 . Évalué à 2.
Je tape sur les devs, mais force est de constater que j'ai vu des sysadmins faire ce genre de choses … voire pire du style débrancher à chaud un des deux disques mirroir d'un RAID, et considerer le disque débranché comme la sauvegarde en cas de pépin lors de l'intervention sur la BDD …
[^] # Re: Trollons
Posté par G.bleu (site web personnel) . Évalué à 6.
C'est marrant de parler de Docker comme un cache-misère, moi si un sysadmin décide de faire de l'ingérence dans les dépendances de mon application, je lui dirais que je n'ai besoin que de Docker. Je résous le problème en faisant de l'ingérence dans les outils qu'il devra utiliser quoi ;-)
Sans attaque personnelle, je suis curieux de savoir dans quel domain tu es sysadmin. De mon point de vu vouloir gérer les dépendances à partir des paquets de la distrib est peine perdue sortie de C/C++ et (j'imagine, merci de me corriger si ce n'est pas le cas) Java.
Les autres langages fournissant un outil de gestion des dépendances adapté, cela ne sert à rien de dupliquer les efforts pour avoir un résultat moins bon, examples:
deux projets ont des dépendances en version différentes, comment faire via apt-get pour que chaque projet utilise la bonne version de la lib ? Pour résoudre ce problème npm et composer installent dans le répertoire du projet, pip a les virtualenv etc.
Pour un projet en python/ruby/php/js une majorité des dépendances ne sont pas packagées dans la distrib, il faut tout re-écrire dans le projet ? (bonjour l'explosion de la complexité et de maintenance…) ou bien tout copier en dur dans le projet ?
Concernant le problème de disparition d'une dépendance dont parle l'article, Docker résous justement ce problème : il suffit de construire l'image du projet à partir d'une image contenant les dépendances et le tour est joué !
[^] # Re: Trollons
Posté par barmic . Évalué à 7.
Pour Java, il ne faut surtout JAMAIS vouloir gérer les dépendances par le système en java. JAMAIS, même pas un peu et il n'y a pas d'exception ou de cas particulier.
Les dépendances sont gérer par ce que l'on appel un classpath. C'est une liste de dossiers ou d'archives jar (des zip) qui sont chargées au démarrage de l'application. Au cas où ça aurait échappé en première lecture, qui sont « chargées au démarrage de l'application ». Donc plus tu en as plus c'est long et lent (le chargement du classpath c'est ce qui consomme le plus au démarrage de la JVM), mais c'est surtout un bon moyen d'injecter une porte dérobée dans une application.
Donc non, pas de gestion de dépendance système wide en java. Personnellement je préfère fournir un « fat jar » qui inclue les dépendances. Oui ça empêche les admin de faire une mise à jour d'une dépendance sans en parler au dev (comme c'est dommage).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par MTux . Évalué à 10.
Ce n'est pas qu'un cache misère. Bien sûr que Docker c'est très bien, le problème c'est que pour beaucoup c'est un moyen de packager une application + ses milliards de dépendance qui vont avec sans se faire chier à documenter. Résultat on exécute le tout mais on ne sait pas comment ça marche, et le jour où ça crashe (à 3h du matin le dimanche bien sûr) on appelle le sysadmin en catastrophe pour tout remonter. Mais vu que l'install n'est pas documentée (c'était plus simple de fournir un unique container Docker) c'est la galère.
Non ce n'est pas peine perdue, à ma connaissance Debian package de tas d'applications capables d'utiliser les dépendances des mêmes dépôts ? Cette mode de vouloir outrepasser les versions de la distribution et avoir du frais est à mon sens récente et est arrivée avec node.
Ma réponse va sembler simpliste mais : tu code ton appli pour qu'elle tourne sur Debian 8 et c'est tout. N'utilise pas de dépendances externes ou en version trop récente. Cet enfer de dépendances est peut-être justement due au fait que tout le monde veut aller trop vite et considère que le problème vient des distributions ? Moi je vois ça dans l'autre sens, on code sur des ecosystèmes inexistants ou exotiques et on fait du forcing/bidouillage pour caser ça en production.
[^] # Re: Trollons
Posté par G.bleu (site web personnel) . Évalué à 4.
Personnellement ma réponse à la problèmatique est exactement inverse : installer pour chaque projet ses dépendances via le gestionnaire de la techno utilisé et ne surtout pas utiliser les paquets du système.
Dépendances minimes du point de vu du sysadmin : l’interpréteur du langage + le gestionnaire de dépendances (bonus combo pour python 3 qui fourni CPtyhon, pip et virtualenv de série dans toutes les installations). Parfois un paquet en plus dans le cas d'un module binaire (par exemple pySSL aura besoin de libopenssl installé) mais c'est plutôt rare
Agnostique vis-à-vis du système : la prod peut être sur Debian, les dev répartis entre Ubuntu et Mac et demain on peut migrer sur Heroku, personne n'aura de soucis
Isolation des dépendances entre les applications : pas de risque de se retrouver avec une maj d'un dépendance pour l'application A qui casse l'application B, pas non plus de risques de se retrouver avec des dépendances implicites qui on été installées par d'autre applications
D'ailleurs en parlant d'Heroku, voir la partie dépendances de leur manifeste sur le concept de "12 factor app"
[^] # Re: Trollons
Posté par barmic . Évalué à 4.
JS a bon dos. cpan, gem, pip,… sont plus vieux que node. Pareil pour les trucs comme maven.
Il y a rien sur Debian (comme sur n'importe quelle autre distrib'). Dès que tu as un besoin un peu pointu ta dépendance tu l'a pas. Rencontré un bug ou avoir une fonctionnalité manquante dans une lib ça arrive aussi très fréquemment. Il y a un moment où tu fais un choix, entre coder en plus pour te contraindre à une plateforme donnée soit utiliser quelque chose de plus récent. Mon choix est très vite fait et si l'exploitant n'est pas content je me plis à ce qu'il souhaite : je lui construit un paquet de la distrib', crée un playbook, un conteneur,… Tout ceux que j'ai rencontré ne voulaient aucune de ses solutions (soient il ne connaissent pas soit ils ne veulent pas apprendre).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Sérieusement, il faut évoluer là. On n'est plus dans les années 90 où la plupart des softs étaient en C/C++ avec des dépendances binaires, donc des dépendances fortes avec les systèmes.
Alors peut-être que ton quotidien consiste à déployer majoritairement des applis C++, mais il n'y a pas que les applis à dépendances binaires dans la vie.
Un projet Node, PHP, python ou autre techno n'a pas de dépendances binaires, des trucs à compiler fortement liés aux systèmes. La seule dépendance qu'ils ont avec le système, c'est le paquet du runtime. Et encore.. un projet réalisé avec PHP 5.3 peut très bien fonctionner avec 5.6 par exemple.
Un programme en NodeJS ou PHP (avec Composer), a toutes ses dépendances avec lui (répertoire vendor/ pour PHP). Sérieusement, qu'est ce que ça peut te faire toi, que ce programme ait ses dépendances avec lui ? En quoi est-ce différent d'un programme dans lequel le développeur aurait développé ses propres libs plutôt que de réutiliser l'existant ? Dans ce cas là aussi, tu forcerais le développeur a mettre à la poubelle ses libs et le forcer à utiliser PEAR ?
De mon point de vue, ce n'est pourtant pas de ta responsabilité.
Je comprend ton point de vue pour ce qui est des projets développés en C/C++ non linkés statiquement, parce que oui, là, effectivement, il y a une forte dépendances avec le système, et que ça peut foutre la merde.
Mais pour du node, du php ou autre langage interprété, je ne comprend pas ta réaction. Je n'ai jamais eu à faire à un admin-sys avec de telles exigences, qui sont d'ailleurs pour moi totalement infondées. Quand je travaille avec un admins-sys en général, il m'impose une version de PHP, une version de base de donnée, une version de rabbit mq etc, bref, une version des outils qui gravitent autour de l'appli. Ce que je peux comprendre parce qu'il n'a pas envie d'avoir un parc hétéroclite et que tous ses serveurs sont en Debian 8 par ex. Va donc pour du PHP de telle version, et je fais avec.
Mais de là à m'imposer à ne pas utiliser des libs externes, non fournis en général par le système, mais par un système de package comme Composer ou Npm, alors là, j'hallucine, je ne comprend pas. Je fais comment alors ? je réécris tout from scratch ? Je ré-invente la roue tous les jours ? Bonjour les coûts et les temps de développements…
D'ailleurs, je comprend encore moins ta réaction puisque pour moi, moins de dépendances avec le système, c'est moins de souci. Tu peux faire cohabiter plusieurs applis ayant des dépendances avec des version différentes, sur un même serveur. Alors que faire cohabiter deux applis PHP qui reposent sur une version de PEAR différente (installée via le système), c'est mission quasi impossible. Et c'est d'ailleurs la raison pour laquelle PEAR n'a jamais vraiment percé, jamais été apprécié par les développeurs. On se retrouve avec des libs vieillottes, pas à jour, donc avec des fonctionnalités manquantes, et donc à devoir réinventer la roue sans cesse. Et si par malheur on voulait faire un upgrade des libs PEAR, il y a de fortes chances que ça casse les vieilles applis déjà en place. Pas cool pour un admin. Alors que depuis l’avènement de Composer, et donc la possibilité d'installer des libs à l’intérieur du projet même, sans conséquence pour le reste du système et des autres applis, c'est bien plus simple d'un point de vue administration (ou alors quelque chose m'échappe), et bien plus simple pour le développeur.
L'évolution de l'informatique converge vers la minimisation des dépendances : autonomie des applications, autonomie des services. Le succès de docker en est l'expression la plus forte. Mettre tout sur la même machine, sur le même système, c'est fini, terminé : c'est trop de contraintes pour tout le monde, trop compliqué pour faire évoluer les applications etc…
En tant qu'admin sys, tu devrais t'en réjouir… À moins que tu n'aimes pas les changements qui s'opèrent dans ton métier ? Il se transforme, il passe de la gestion pure et dure d'une machine et de son OS à la gestion d'un Cloud, de containers, de micro-services et j'en passe. Nouvelles méthodes, nouvelles façon de voir les choses. Tout ça pour permettre d'être plus réactif aux demandes des utilisateurs, de pouvoir chipper une nouvelle fonctionnalité rapidement, sans à se poser de question "est ce que ça ne va pas casser l'appli Y?", ou encore "comment je fais pour implémenter cette fonctionnalité parce que l'admin-sys veut pas que j'utilise telle lib, qui pourtant me permettrait de coder ça en 1 heure ?" .
Fournir et faire évoluer rapidement un service suite à des demandes utilisateurs, c'est le but de tous services informatiques non ? (c'est le seul truc qui n'a pas changé ça ;-)
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
D'ailleurs, "npm install -g" suxx, du coup.
[^] # Re: Trollons
Posté par fearan . Évalué à 3.
Je vais peut être parler à sa place, mais en tant qu'admin sys ça devrait lui faire peur. Que se passe t'il si le module intégré link vers une version particulière et que cette dernière est trouée? Comme chaque appli vient avec ses propre dépendances il risque de se retrouver avec 15 version différente avec 12 failles différentes.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Trollons
Posté par Juke (site web personnel) . Évalué à 5.
La meme chose que si le dev n'a pas utilisé et lib et codée lui meme une faille ?
[^] # Re: Trollons
Posté par barmic . Évalué à 5.
En quoi est-ce que c'est au sysadmin de jouer avec les dépendances de l'application ? Si tu as une telle faille, ça revient forcément au développeur de faire une nouvelle livraison. On ne peux pas reprocher d'un coté au développeur de ne pas correctement gérer les dépendances de son application et de l'autre faire ce que tu veux avec ces même dépendances.
Lorsqu'il s'agit de bibliothèques système wide oui le sysadmin as tout pouvoir pour mettre à jour en suivant ce que lui propose l'OS.
Quand tu requière le support du développeur (que ce soit pour un projet spécifique ou via un éditeur plus ou moins gros), tu te met à dos au mieux les développeurs au pire le contrat qui les lie à toi.
De la même manière que ça crispe les adminsys de voir des utilisateurs installer leur « propres » logiciels, ça crispe les développeurs de voir le sysadmin retoucher n'importe quoi dans l'application.
Soit tu fais du devops et il n'y a pas de frontière dev/sysadmin, soit il vaut mieux rester dans son domaine de compétence et communiquer avant de jouer ainsi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Je dirais que le sysadmin n'a pas à vérifier les dépendances de chaque appli, ce n'est à mon avis pas son rôle. Parce que dans ce cas là, il vérifie aussi le code de toutes les applis que les devs de sa boite font, sans parler de tous les outils qu'il doit installer sans passer par apt (bah oui, il y a plein d'outils que l'on peut avoir besoin absolument mais qui ne sont pas les dépôts de la distro). Il n'a alors jamais fini.
Tout ce qui est problématique de sécurité dans le code, je dirais que ce serait plutôt à l'équipe QA de vérifier tout ça, quand ce n'est pas aux développeurs de le faire (encore faut-il avoir une politique de sécurité).
Le sysadmin par contre, son rôle, IMHO, est de limiter les dégâts en cas d'éventuels attaques via des trous de sécu. C'est à dire cloisonner les applis (container par ex), ne les laisser accéder que ce à quoi elles ont droit d'accéder (firewall &cie), et mettre en place du monitoring pour détecter les comportements inadéquates.
Et si il découvre qu'il y a effectivement des problèmes, voir qu'il découvre à ses heures perdues une faille dans un paquet d'une appli, il fait comme pour tout logiciel qu'il installe sur son infra : il fait passer l'info en upstream (à Debian si c'est un paquet debian, aux dev de sa boite si c'est une appli interne, etc..).
Enfin bon, c'est en tout cas la manière dont je vois les choses.
[^] # Re: Trollons
Posté par Michaël (site web personnel) . Évalué à 7.
C'est parceque tu vois ça avec tes yeux d'utilisateur de Debian, mais regardons le problème du point de vue du programmeur JavaScript. Ce programmeur fait partie d'une communauté qui se retrouve autour d'un langage mais travaille dans un environnement hétérogène. Ainsi les développeurs JavaScript utilisant des dépendances externes se retrouvent confrontés aux problèmes où le binding qu'ils écrivent ne marchent pas sous la distribution bla bla Linux parceque la zlib y est en version 2.0 tandis que sur leur système glop glop Linux elle est en version 2.0.1 – et que des différences subtiles créent des problèmes difficile à reproduire. L'introduction d'un système de packages ad-hoc permet donc à cette communauté de se réunir autour d'un éco-système relativement homogène, et d'introduire une abstraction pour traiter les cas particuliers liés aux différents systèmes.
Cette stratégie répond donc à un problème bien concret qu'elle résout – non sans amener son propre lot de problèmes, mais apparemment il n'y a aucune solution qui permet de gagner sur toute la ligne, on est donc amené à faire des compromis en fonction de ses priorités.
[^] # Re: Trollons
Posté par barmic . Évalué à 10.
De toute façon l'autre solution c'est de faire comme go : on compile statiquement et on rend littéralement impossible une gestion système wide des dépendances. On empêche aussi le sysadmin de toucher aux dépendances. C'est une manière violente de faire un gros fuck au monsieur qui veut une gestion « propre » des dépendances :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par mh-cbon . Évalué à 2.
J'essaie de comprendre ce qu'il est bancal,
le semver qui te fait changer de version ? => shrinkwrap ?
Vu mon support de samba sur fedora (truc rygel qui me balance des c**** dans journald et va te lever tôt pour corriger le bouzin) je suis bien content qu'il ne s'occupe pas de TOUS les paquets….
# npm, comment dire...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 23 mars 2016 à 12:04.
On peut se poser aussi la question d'utiliser npm tout court, qui est un système de paquet complètement pourri de mon point de vue, où, pour un même projet, on se voit à télécharger 20 versions du même paquet parce que le projet dépend de 40 paquets qui utilisent 20 versions différentes du même paquet (sans compter les autres versions de paquets similaires, parce que bien entendu, ces 40 paquets qui ont besoin d'une même fonctionnalité, ne vont pas utiliser la même lib qui propose cette fonctionnalité).
L'installation de certains outils utilisant npm est hallucinant en terme de temps de téléchargement et d'installation. Sans compter que, puisque qu'il y a 20 versions d'un même paquet, alors on se retrouve avec ces 20 versions en mémoire et du code similaires exécutés bien entendu 20 fois au chargement (pour une seule instance de l'outils).
C'est un gachi de ressources hallucinant, tant à l'installation (bande passante &co, même si npm gère un cache), qu'à l'exécution.
Et je ne parle pas des nombreux paquets qui n'ont rien à voir avec JS, mais qui sont dans npm parce que leurs auteurs ont trouvé sympa de pouvoir installer leurs logiciel via npm. WTF.
PS: corollaire du problème de télécharger 20 versions d'un même paquet : les statistiques de téléchargement sur npmjs.org sont totalement bidons et ne veulent rien dire au final.
[^] # Re: npm, comment dire...
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Et tu ne parles même pas de "npm search" qui utilise un temps d'exécution calamiteux.
[^] # Re: npm, comment dire...
Posté par scullder . Évalué à -1.
Je pense pas que le fait d'utiliser 50Mo de ram en plus soit un argument recevable de nos jours.
Le problème est plutôt "est-ce que ça passe à l'échelle ou pas ? jusqu'à combien d'utilisateurs en parallèle ? combien ça coûte en temps de développement / admin sys d'optimiser ? pour quel bénéfice ?".
Si tu passes du temps à optimiser des dépendances pour augmenter les performances de 2% pour un cas particulier, je pense sincèrement que c'est inutile (enfin c'est intéressant pour moi mais je vais pas prendre le risque de casser des applis au travail pour ça).
Si tu passes du temps pour monter d'un ordre de grandeur dans le passage à l'échelle, oui c'est intéressant si tu en as l'utilité…
# Dépendances
Posté par barmic . Évalué à 8.
On peut se poser la question pour un projet quelque soit le langage quand les dépendances augmentent.
Un projet en C aura tout autant de problème que celui en JS si l'une de ses dépendances n'est plus maintenue, casse la compatibilité, a une faille de sécurité, etc
Le undeploy d'une dépendance n'est qu'un cas particulier de ces problèmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par Bruno Michel (site web personnel) . Évalué à 9.
Oui, mais le risque est démultiplié en javascript pour 2 raisons :
[^] # Re: Dépendances
Posté par Clément V . Évalué à 3.
Je connais très mal node et je me demandais pourquoi la fonction n'utilisait pas plus les méthodes de String.
Si j'essaye :
Ça marche avec gjs (basé sur SpiderMonkey que je suis plus habitué à utiliser) mais node ne connait pas repeat. En fait, en regardant plus en détails, j'ai l'impression que
new Stringdans node donne un objet différent des chaines primitives et aucun n'a les méthodes standard de String. Pourquoi ce manque ? Ou c'est moi qui confond des extensions de SpiderMonkey avec le standard ?La bibliothèque standard pauvre n'est-elle pas plus un problème propre à node plutôt qu'à javascript ? Un logiciel utilisant javascript devrait fournir les classes de bases (Object, Function, String, Array, Math, …) et d'autres propres au contexte (par exemples les objets window et document dans un navigateur web, node a console et, j'imagine, quelques autres).
[^] # Re: Dépendances
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Non c'est juste que certaines versions de Node (entre NodeJS v4.0+, la serie NodeJS v0.12 toujours maintenue et Io.js, j'y perd mon latin) utilise une vieille version de V8. La fonction repeat n'est apparu à priori que dans Chrome 41, ce qui correspond à V8 4.1. Or V8 4.1 n'est utilisé que depuis io.js v1.0.3 et donc NodeJS v4.0.0. Donc il y a à peine plus d'un an.
Alors que Spidermonkey l'implémente depuis Firefox 24, c'est à dire septembre 2013.
[^] # Re: Dépendances
Posté par feth . Évalué à 6.
Est-ce que je dois comprendre que tu serais prêt à créer un grand mouvement pour l'adoption d'un meilleur langage de programmation web
Certes tu n'es peut-être pas encore convaincu de ta mission, mais c'est un détail, car elle est grande et porte en elle un espoir pour le futur du monde large toilé !
[^] # Re: Dépendances
Posté par Ytterbium . Évalué à 6.
C'est python ça, non ?
[^] # Re: Dépendances
Posté par totof2000 . Évalué à 1.
Non, surtout pas. Python est le VB du libre. Une horreur. Les adorateurs du Serpent pensent que ce langage est lisible parce qu'il force à indenter, mais c'est une illusion. Python est loin d'être lisible (surtout quand tu te mets à mettre au beau milieu de ton code des paradigmes fonctionnels : ça casse l'homogénéité et la fluidité de la lecture). Il y a d'autres problèmes avec Python que je ne détaillerai pas parce qu'il est tard, mais pour donner une idée, la façon dont il t'oblige à faire un print de ligne sans retour chariot est siplement abominable, et résume bien l'esprit du langage.
[^] # Re: Dépendances
Posté par Ytterbium . Évalué à 7.
print(text, end=''), il y a pire non ? Surtout que personnellement, je fais bien plus souvent des print avec retour de chariot que sans, donc j'apprécie le fonctionnement par défaut. Après, forcément, si on utilise une version d'il y a plus de 5 ans…[^] # Re: Dépendances
Posté par G.bleu (site web personnel) . Évalué à 4.
Si Python est difficile à lire… On peut avoir un exemple de langage simple à lire ?
Et pour le print sans retour charriot, il suffit de mettre une virgule à la fin du print en python2
Et il y a l'argument "end" qu'on peut spécifier en python3 (oui, il ont amélioré la lisibilité ;-)
Bref si tu en es à ce genre d'arguments c'est que tu ne connais pas Python.
[^] # Re: Dépendances
Posté par barmic . Évalué à 2.
Comment est-ce qu'on minifie du code python ? :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par flan (site web personnel) . Évalué à 7.
Il suffit de prendre le code "compilé" (le bytecode généré à la première exécution) :)
[^] # Re: Dépendances
Posté par Pierre Tramo (site web personnel) . Évalué à 7.
Bonne nouvelle à propos de python!
Left-pad est enfin sur pypi: https://pypi.python.org/pypi/left-pad/
[^] # Re: Dépendances
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Non, c'est Elm. Indiscutablement.
[^] # Re: Dépendances
Posté par xcomcmdr . Évalué à 3.
C'est Ruby, c'est ça ? :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Dépendances
Posté par totof2000 . Évalué à 0.
Non plus. Ruby est loin d'être parfait.
[^] # Re: Dépendances
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Oui, j'aimerais bien voir un autre langage disponible dans les navigateurs (ou même plusieurs via WebAssembly). Côté serveur, la question ne se pose pas trop, on a déjà le choix d'utiliser Go, Ruby, Python, Erlang, Elixir et plein d'autres langages plus sensés que le JS.
En ce moment, je regarde du côté d'Elm. Ça a l'air pas mal mais je ne connais pas encore assez pour dire s'il répond aux critères. Le langage est jeune et a encore des défauts de jeunesse, mais on sent qu'il a du potentiel.
[^] # Re: Dépendances
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Elm :
Pas check. L'écosystème d'Elm est encore trop jeune et trop maigre :( On arrive assez vite aux limites. Mais c'est en pleine progression actuellement.
Check
Mega-check
Pas check. La courbe d'apprentissage de Elm est plutôt raide, quoiqu'en disent ses promoteurs. Pas tant dans le langage dont on fait assez vite le tour, mais dans le fait de prendre de nouveaux réflexes et de s'adapter aux contraintes d'un langage purement fonctionnel.
Check
Je sais pas si on a un Nonobstant ici, mais j'ai les cheveux de la barbe qui poussent depuis que je fais du Elm, quant à gagner au loto, faudrait déjà que je joue, mais je suis sûr que je gagnerais. Mais bon, j'ai déjà un ordinateur et un fauteuil confortable, de quoi aurais-je donc besoin de plus ?
[^] # Re: Dépendances
Posté par Le Gab . Évalué à 10.
Non mais t'as vu un peu le code en question, je veux bien que le dev soit féneant, qu'il ne veuille pas réinventer la roue, mais utiliser des modules tiers pour un traitement de chaîne aussi basique, c'est à pleurer. C'est de l'ordre du snippet ici vu qu'il manque de la doc, des tests et que ça ne couvre qu'un cas de figure.
Le truc, c'est que c'est récurrent en .js. des milliers de petits modules de 10 lignes minimum.
Il faudrait calmer la fougue de ces jeunes devs .js qui se prennent pour les rois du monde et affiche du CTO par-ci et du Co-Founder par là pour des trucs triviaux.
[^] # Re: Dépendances
Posté par barmic . Évalué à 4.
Ça n'a rien avoir avec le code. Tu as une dépendance vers disons, OpenSSL, ta distrib' décide de virer ta lib, soit tu l'a téléchargée avant soit t'es KO.
Ce dont tu parle c'est de la multiplication des dépendances liés, comme dis au-dessus, à la pauvreté de la lib standard. Pour pallier à ça je crois que les bibliothèques et les frameworks intègrent chacun un set de fonction de ce genre. C'est palliatif.
Il aurait écris des Gio de doc et fait 100 millions de tests le undeploy aurait eu précisément la même conséquence.
Vu les projets qui ont cassé, je ne m'aventurerais pas à affirmer que ce sont des « jeunes devs fougueux ». Par contre que JS s'affirme comme un langage de très haut niveau avec une bibliothèque standard plus complète, ça ne me choquerait pas. Il manque probablement un projet à la boost qui soit généraliste et qui ai pignon sur rue.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par Le Gab . Évalué à 3.
J'ai bien compris ce sur quoi vous argumentiez.
Mais je ne pense pas que npm aurait viré du jour au lendemain un truc comme ssl si ssl.com venait à les ennuyer.
Evidemment qu'il s'agit d'un troll de ma part mais justement, cela étant, peu importe la taille du projet en question, ils ont quand même eu recourt à un module trivial de qualité médiocre.
[^] # Re: Dépendances
Posté par barmic . Évalué à 1.
Tu base tout sur la qualité/l'image ou non du module, pour moi ce genre de réflexion s'approche du « ça n'arrive qu'aux autres ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par Anonyme . Évalué à 4.
Au moins en C, tu as une librairie standard.
Quand on voit ce que font ces 11 lignes de codes, on se demande quand même si le soucis c'est qu'il ne faille pas installer un module pour faire un strcmp quoi…
[^] # Re: Dépendances
Posté par Sufflope (site web personnel) . Évalué à 2.
Quand on voit que ces 11 lignes n'ont rien à voir avec strcmp, on se demande quand même si le souci c'est pas les développeurs C, ou leur condescendance au moins.
[^] # Re: Dépendances
Posté par Antoine . Évalué à 9.
Surtout que vanter la bibliothèque standard du C, c'est un peu l'hôpital qui se fout de la charité… On parle bien du langage où les fonctions de traitement de chaîne les plus connues posent des problèmes de sécurité ? Où il n'y a pas de conteneur associatif en standard ? Où la prise en charge des textes non-ASCII est pourrie ?
[^] # Re: Dépendances
Posté par barmic . Évalué à 3.
Tu la trouve où leftpad dans le norme C ? (choisie la version que tu veux, y compris celle en préparation si ça peut t'aider :) )
Sachant que le code C équivalent est presque identique (on explicite plus les types et on fait une allocation mémoire de la bonne taille plutôt que de concaténer).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par diorcety . Évalué à 6. Dernière modification le 24 mars 2016 à 09:40.
Mouai…, on va dire si je comprend bien a quoi sert la fonction, c'est faire des affichages avec de l'indentation. Alors oui il n'y a pas la même fonction pour faire ça en C, mais il me semble que les *printf sont utilisés pour faire ça dans plein de logiciel open source. Alors certes il y a certainement des helpers, c'est moins optimisé, mais pas besoin d'importer une dépendance. Bref, je suis pas sur de la pertinence de comparer les fonctions de base fournies pas les langages. On va dire que c'est plus l'état d'esprit et la "complexité" d'ajouter une bibliothèque qui fait que personne n'ajouterait une dépendance pour ça en C.
[^] # Re: Dépendances
Posté par shbrol . Évalué à 5.
produira:
Limité a l'espace pour le caractère de remplissage, variantes sprintf/snprintf pour travailler en mémoire sans affichage, avec toutes les blagues habituelles en cas de dépassement du buffer.
[^] # Re: Dépendances
Posté par barmic . Évalué à -3.
Presque c'est snprintf qui fait le boulot. Le padding ça ne sert pas qu'à l'affichage.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Dépendances
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
Leftpad en C est là : https://github.com/lovenunu/leftpad-c
[^] # Re: Dépendances
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Oui, ce genre de module montre la faiblesse d'une lib standard.
Si ça peut rassurer, String.padStart et String.padEnd arrivent dans ES7
https://github.com/tc39/proposal-string-pad-start-end
https://bugzilla.mozilla.org/show_bug.cgi?id=934776
# Quitte à partir dans tous les sens ...
Posté par El Titi . Évalué à 1.
Moi ce que ça m'évoque, c'est que ledit Azer, outre sa susceptibilité plus ou moins mal placée, serait bien inspiré de lire ceci:
http://www.amazon.fr/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
[^] # Re: Quitte à partir dans tous les sens ...
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2.
Il nous parle d'opensource mais ses projets ne comportent pas de mention de la licence utilisé surtout.
M'enfin quand même, pouvoir dé-publier un truc publié de longue date sur npm ça me semble surtout une anti-fonctionnalité. Ce qui n'empêche pas que je comprends tout à fait la réaction du type face à ces menaces sur le droits des marques (rien à voir avec le droit d'auteur ou copyright d'ailleurs)
[^] # Re: Quitte à partir dans tous les sens ...
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Si, la licence est mentionnée (même si c'est relativement bien caché). C'est du WTFPL.
Oui, cette fonctionnalité est discutable. Mais je trouve encore plus discutable que npm puisse annuler la dépublication de l'auteur.
[^] # Re: Quitte à partir dans tous les sens ...
Posté par Psychofox (Mastodon) . Évalué à 9. Dernière modification le 23 mars 2016 à 16:41.
En quoi c'est discutable si ce logiciel est fourni sous une licence libre ? Faut prendre ça comme quelqu'un qui en publie un fork tout à fait identique. À partir du moment où le nom du module n'est pas une marque protégée il n'y a aucune raison que ça pose problème à quiconque.
# IPFS à la rescousse
Posté par Benjamin Henrion (site web personnel) . Évalué à -1.
Personne n'apprends vraiment les lessons de ce genre de débacles.
Le problème ce sont les humains qui viennent modifier les repos à tour de bras (y compris chez Debian), même si certains utilisateurs ne veulent pas d'updates.
La solution est de mettre ces "repos" dans un système immutable comme IPFS:
https://medium.com/@noffle/you-might-be-interested-in-checking-out-https-github-com-whyrusleeping-gx-75e7c90db762
[^] # Re: IPFS à la rescousse
Posté par El Titi . Évalué à 2.
Vooouuus a-vez pefectly reason
[^] # Re: IPFS à la rescousse
Posté par barmic . Évalué à 5.
Qu'entends-tu pars là ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: IPFS à la rescousse
Posté par mh-cbon . Évalué à 0.
je n'ai pas suivi l'affaire depuis un moment, mais bon,
https://github.com/ipfs/npm-go-ipfs
ipfs ou dht, ce serait bien ouais, au moins car l'idée me plait…. : )
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: violation de copyright, vraiment ?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3.
En tout cas en Europe c'est comme ça. Aux USA je ne sais pas.
D'un autre côté le FUD suffit en général.
[^] # Re: violation de copyright, vraiment ?
Posté par Le Pnume . Évalué à 4.
Peut être que les avocats de kik ont décidé qu'ils devaient justifier un minimum le forfait annuel qui leur est versé. Mettre en demeure un pov'développeur indépendant, ça occuperait 1 heure de temps d'un stagiaire et permettrait de se faire mousser pour renégocier le dit forfait.
Et qu'aux USA,
n'est pas un problème en soit pour attaquer
[^] # Re: violation de copyright, vraiment ?
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Oui, je voulais parler de trademark. Kik.com a une API Rest et veut proposer un SDK en nodejs pour l'utiliser. Ils ont donc contacté l'auteur du module kik sur npm pour essayer de négocier de pouvoir récupérer le nom de ce module pour leur SDK. Derrière, ça a vite dégénéré avec des noms d'oiseaux.
L'histoire vu du côté Kik : https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d
[^] # Re: violation de copyright, vraiment ?
Posté par Lutin . Évalué à -2.
L'agressivité du mec est carrément drôle. En tout cas ça donne un autre point de vue sur l'histoire, ils (kik) ont été plutôt polis.
[^] # Re: violation de copyright, vraiment ?
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
C'est peut-être poli mais ils ont un petit peu sorti l'artillerie lourde et les menaces dès le deuxième mail alors qu'il n'avait répondu encore que : "Sorry, I’m building an open source project with that name."
[^] # Re: violation de copyright, vraiment ?
Posté par BFG . Évalué à 3.
http://cryto.net/~joepie91/blog/2016/03/23/reflections-on-npm-gate-one-day-later/
[^] # Re: violation de copyright, vraiment ?
Posté par laurentb (site web personnel) . Évalué à 2.
Ils ont tout fait pour le provoquer, et puis de se plaindre qu'il est pas poli. Je déteste ce genre de fausse politesse, la demande de kik est intolérable, que ce soit fait poliment ou non.
Ceci, pour ma part, j'aurai tout simplement ignoré les e-mails (dans le sens même pas de réponse) tant qu'il n'y a pas une avocat derrière ; on voit bien que les mecs qui gèrent npm sont de parfaits amateurs.
[^] # Re: violation de copyright, vraiment ?
Posté par groumly . Évalué à 0.
Intolerable? Tout fait pour le provoquer?
Le mec:
- demande gentiment
- ensuite, cherche un arrangement amiable, mais se fait insulter copieusement,
- continue a cherche un areangement amiable, et se fait toujours insulter copieusement
Je vois pas ce qu'il ya d'innacceptable la dedans.
Il aimerait bien avoir qq chose qu'azer avait, il lui demande s'il peut l'avoir, et demande ce qu'azer voudrait en echange. Mentionner les avocats au deuxieme email etait tres maladroit, certes, mais le ton des mails reste cordial et poli.
Quand a u fait qu'npm ait lache le nom sans meme recevoir une demande formelle d'un avocat, c'est un autre probleme.
Autre question pour toi, si les roles etaient inverses, est ce que tu considererais la demande d'azer inacceptable?
Certains ici trouvent inacceptable le refus de mozilla que debian utilise la marque ff (bon, plus maintenant), en quoi est ce different quand les roles sont inverses?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: violation de copyright, vraiment ?
Posté par Sufflope (site web personnel) . Évalué à 2.
Bah c'est pas différent. Dans les deux cas tu as le Méchant© (il est facilement reconnaissable, il a un rire sardonique, quand il apparaît à l'écran il y a de la musique symphonique dominée par les cuivres, et c'est la structure de type société) qui opprime le Gentil®™ (il est facilement reconnaissable, il sourit benoîtement, quand il apparait à l'écran il y a majoritairement des cordes, et c'est celui qui est Panurge-compliant).
[^] # Re: violation de copyright, vraiment ?
Posté par laurentb (site web personnel) . Évalué à 2.
La le contenu de la demande n'est pas gentille. Ce n'est pas parce que c'est poliment dit et sans insulte que c'est sympa.
Si je demande poliment de me donner le contenu de ton portefeuille, est-ce que tu dois le faire parce que j'ai été poli ? Est-ce que je suis un mec sympa ? Est-ce que si tu m'insultes en retour, je peux l'exploiter à mon avantage ?
En plus :
"our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that"
Je ne comprends pas ce que ça veut dire. L'identité des interlocuteurs n'a aucune importance.
# Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 10.
On pourrait croire que left-pad est un exemple qui sort de l'ordinaire… mais en JS, non, malheureusement.
http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/
Mais comment une lib qui fait quelque chose d'aussi compliqué que vérifier qu'un objet est un entier positif ou nul peut-elle avoir 3 dépendances ? C'est simple :
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 9.
Je ne comprends pas pourquoi est-ce qu'un module n'a pas émergé avec un set de fonctions généralistes de ce genre ? Ça permet de tirer qu'une seul dépendance et d'avoir un set cohérent (on peut imaginer qu'elles s'utilisent plus naturellement les unes avec les autres). Bref un peu ce que fait boost en C++ ou guava en java.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Bah le pire, c'est que ça existe ce genre de lib, comme lodash… Et c'est pourtant une lib plutôt connue.
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 5.
Je n'ai pas de mal à comprendre pourquoi lodash n'a pas cette popularité. Elle vient avec une façon de penser ou d'organiser son code particulière. Peut être que JS est fonctionnel (il y en a qui disait ça dans un journal précédent), mais beaucoup de développeurs JS ne le voient pas comme ça. Leur imposer une tel organisation, ça ne passe pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 4.
Est-ce que les minifiers JS savent virer du code mort ? Parce que sinon il y a une vrai raison à découper en petits modules qui vont être fusionnés par grunt, gulp ou webpack plutôt que d'utiliser un gros truc dont on utilise finalement pas grand chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par CrEv (site web personnel) . Évalué à 3.
Un minifieur non, heureusement.
Un compilateur JS->JS oui. Google Closure Compiler sait le faire (et plein d'autres choses très bien). En général ça demande juste d'instrumenter un peu le code JS, en déclarant des types et autres choses du genre, mais c'est possible et très efficace. Ça fait aussi de l'inlining par exemple.
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 4.
Donc il faudrait en choisir un et le module devrait venir avec en dépendance le compilateur qui va bien. C'est pas hyper pratique et de ton coté tu ne peux pas instrumenter le code des modules sans les forker ce qui demande de les renommer, de les republier, de gérer ces patchs,…
À moins qu'il soit possible de le faire (de manière utile) sans instrumenter l'ensemble du code.
Il me semble que c'est une particularité importe du JS pour la question des dépendances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Voici le point de vue d'un développeur connu pour faire beaucoup de modules avec peu de lignes de code :
https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328
[^] # Re: Autres exemples rigolos
Posté par CrEv (site web personnel) . Évalué à 4.
Cet article est bien intéressant, d'autant plus que contrairement à pléthore qu'on peut lire aujourd'hui, celui-ci a été écrit il y a plusieurs mois, et donc de fait loin de la polémique actuelle.
Et d'un côté il a raison : même si le module est là pour éviter une oneliner avec 2 conditions ça reste intéressant, pas envie de se souvenir justement de comment ça s'écrit.
Là où la question est beaucoup plus intéressante c'est pourquoi on a besoin de ces oneliners ?
Evidemment la réponse est dans la pauvreté de la lib standard js…
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 10.
Je ne suis pas du tout d'accord. On se retrouve immédiatement avec des graphes de dépendances énormes et le moindre projet n'est plus du tout maintenable : quand tu as une dizaine de dépendances, tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible), tu connais leur licence, tu peux avoir un ensemble à peu près cohérent, tu limites les doublons de code.
Avec le JS, le moindre projet va dépendre de centaines de développeurs indépendants qui mettent leur code à jour chacun de son côté, avec des licences potentiellement exotiques, qui peuvent ajouter des bugs et affecter en cascades d'autres dépendances intermédiaires, etc.
Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 2.
C'est impossible avec pip ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 10.
Si, en t'accrochant bien, tu peux sûrement faire un projet avec des centaines de dépendances directes faites par autant de développeurs et sans aucune communauté derrière. Par contre :
* chaque dépendance ne sera présente qu'une seule fois (impossible de charger dans le même programme plusieurs versions de la même lib).
* ton graphe de dépendance ressemblera sûrement à une étoile et sera moins joli : tu n'auras pas à trouver que X dépend de Y qui dépend de Z qui dépend de T qui dépend de U qui dépend de V qui vient d'amener une incompatibilité.
Théoriquement, pypi pourrait très bien être pollué de dizaines de milliers de packages de deux lignes.
En pratique, la qualité moyenne des packages Python actuels (je ne parle pas des paquets Python 2.1 qui n'ont pas été mis à jour depuis 15 ans) est franchement pas mal. La majorité des paquets que j'utilise ont très peu de dépendances (quand ils en ont) sont publiés sur pypi, respectent tous la même norme de code (PEP008), ont une doc propre mise à jour automatiquement sur readthedocs, des tests lancés sur travis.ci, sont hébergés sur Github avec la possibilité de remonter des bugs. Encore mieux, je peux la plupart du temps créer des paquets .deb ou .rpm propres sans rien toucher.
[^] # Re: Autres exemples rigolos
Posté par Juke (site web personnel) . Évalué à 3.
tu fais ça avec python stdeb ?
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 3.
Oui, mais via un outil maison pour appliquer stdeb sur toutes les dépendances avec d'éventuels patches.
[^] # Re: Autres exemples rigolos
Posté par CrEv (site web personnel) . Évalué à 3.
Oué mais tu interprète mal ce que je viens d'écrire. Son discours est de dire qu'il est mieux pour soit, pour son esprit, pour son développement de retenir la dépendance qui a un nom clair que le oneliner (dans le meilleur des cas) assez imbitable (dans la majorité des cas) qui va faire le même taff. Son exemple sur zéro positif/négatif est assez intéressant dans ce sens. De toute façon, s'il n'existerait pas en module npm tu ferais quoi, tu l'écrirais une première fois. Puis si tu dois l'utiliser à plusieurs endroits de ton code, tu en fais un helper, une fonction quelque part. Et comme c'est un helper tu commence à le sortir de ton métier. Puis de ton projet car en vrai tu l'utilises dans plusieurs. Et voilà pourquoi tu crées un module pour ça. C'est plutôt logique.
Après qu'il y ait un problème avec le JS et / ou npm est une toute autre chose (et je pense que c'est le cas, mais je ne parlais justement pas de ça).
Si je ne me trompe c'est quand même l'intérêt aussi de semver. Tu as prévu ton code pour fonctionner avec telle version, tu sais que si upgrade il y a et que semver est utilisé ça ne va rien cassé (parce que tu montera que sur des mineurs par exemple). Si la montée de ton framework t'intéresse (genre django, express, etc) c'est tout autre chose, c'est un élément vraiment central. Mais dans la majorité des cas ton upgrade devrait de toute façon être motivé par une vrai raison. Tes dépendances elles ne vont pas se mettre à jour automatiquement, si tu montes en version c'est que tu le veux bien au fond.
C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.
[^] # Re: Autres exemples rigolos
Posté par Sufflope (site web personnel) . Évalué à 0.
Non ça c'est pas semver c'est seminaire.
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 4.
Tu ne peux pas pousser à fond cet argument sans le vider de sa substance. Le problème n'est d'avoir des dépendances et un graphe de dépendance quelconque. Le problème est d'avoir beaucoup de dépendances et un graphe de dépendance compliqué.
Si tu as dix dépendances qui n'ont quasiment pas de dépendance, il est humainement possible de s'en occuper.
Si tu as cent dépendances qui ont chacune un graphe de dépendance complexe (tu augmentes fortement la probabilité qu'il y ait un problème dans une dépendance de dépendance de dépendance, dans un code que tu ne maîtrises absolument pas), ce n'est plus humainement possible de s'en occuper.
Ce n'est pas un problème de qualité, c'est un problème de quantité. Et en pratique, ce problème arrive avec JS, pas avec Python.
[^] # Re: Autres exemples rigolos
Posté par CrEv (site web personnel) . Évalué à 2.
A moins que tu utilises d'une manière que je ne connais pas bien, tu ne gère jamais toutes ces dépendances. Tu vas par exemple avoir une dépendance à babel qui lui utilise d'autres dépendances. Chacun s'occupant de ses dépendances. Jamais tu n'as à gérer l'ensemble de ton graph de dépendance.
C'est une question d'usage aussi, quand je fais du JS j'ai peu de dépendances, comme lorsque je fais du ruby.
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 4.
Oui, c'est la théorie. Ça implique de faire confiance à toutes tes dépendances. On peut trouver du bon et du moins bon dans tous les langages ; mais encore une fois plus tu as de dépendances différentes, plus tu as de chances de retrouver avec une dépendance foireuse dont une sous-dépendance te posera problème.
C'est beaucoup plus facile de faire confiance à 3-4 personnes qu'à 300 ou 400. À nouveau, le problème n'est pas qualitatif mais quantitatif.
Oui, nous sommes d'accord. Tu peux faire du mauvais ou du bon code avec n'importe quel langage. En théorie, du moins. En pratique, la qualité moyenne (je ne parle pas de toi spécifiquement !) varie fortement d'un langage à l'autre.
[^] # Re: Autres exemples rigolos
Posté par barmic . Évalué à 2.
Logiquement tu ne t'intéresse qu'à tes dépendances direct et si tu utilise ces dépendances c'est que tu pense qu'elles sont assez malines pour faire de même. C'est l'unique façon de faire si tu ne veux pas forker tes dépendances pour jouer à mettre à jour une dépendance de ta dépendance directe.
Il n'y a rien de complexe à savoir quelle dépendance n'est pas à jour dans tes dépendances et ce même si tu en avait plusieurs centaines de milliers. Prévoir la migration vers une version suivante qui casse ça n'arrive pas tous les jours et tu n'a pas besoin de le faire dans la seconde (pour les mises à jour de sécurité c'est différent, mais ça casse rarement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres exemples rigolos
Posté par flan (site web personnel) . Évalué à 4.
Il faut donc analyser la qualité de chaque dépendance. Ça prend du temps, surtout quand on voit les absurdités montrées plus haut (franchement, qui penserait que vérifier qu'un objet est un entier positif demande 3 dépendances ?!?). Faire ce travail pour quelques projets ne me pose pas de problème particulier, le faire pour plusieurs centaines m'en pose beaucoup plus.
[^] # Re: Autres exemples rigolos
Posté par groumly . Évalué à 5.
Ce que tu dit est vrai dans un monde ou la gestion des dependances n'a pas de cout.
En pratique, se taper la mise a jour d'un grand nombre de dependance, trouver ceux qui sont abandonnes, et se farcir des blagues comme celles d'hier, c'est tres loin d'etre gratuit.
Quand c'est pour des one liners du genre return x > 0; ca devient un peu du n'importe quoi.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Autres exemples rigolos
Posté par mh-cbon . Évalué à 2.
bien content de lire que tous les trucs que je n'ai jamais utilisé sont pourris, babel first. là dessus me --> []
# 1 fonction par module ?
Posté par Jiehong (site web personnel) . Évalué à 5. Dernière modification le 24 mars 2016 à 10:05.
Ça choque personne que le module ne possède qu'une seule fonction ?
Édit : bon, j'ai vu le commentaire précédent, et le lien donné qui parle de ça exactement.
[^] # Re: 1 fonction par module ?
Posté par G.bleu (site web personnel) . Évalué à 6.
Moi, avant ton edit, ça me choquait que ton commentaire ne fasse qu'une seule ligne ;)
[^] # Re: 1 fonction par module ?
Posté par KiKouN . Évalué à 2.
C'est déjà mieux qu'aucune.
Quoique, un module pour définir quelques constantes, ça se trouve aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.