Bon, finalement, j'ai fini par envoyé un mail à la FSF pour leur demander leur avis.
Et la réponse est… qu'il n'y a pas de réponse simple.
Comme je le pensais, selon la personne qui m'a répondu, il peut être très compliqué de déterminer si le code enlevé ou encore, si du code refondu peut avoir encore des "traces" ou pas du code original. J'imagine qu'il entend par là que le code refondu, même si syntaxiquement il n'est plus le même, peut faire tout de même la même chose ou très inspiré du code original. (la logique globale, ou l'idée générale de l'algo peut rester la même). Et dans ce cas, le contributeur reste plus ou moins l'auteur du code refondu.
Il m'a indiqué aussi que dans certaines boites, quand ils veulent refondre quelque chose et en être l'unique détenteur du copyright, ils font appel à quelqu'un qui n'a jamais vu le code original. Ainsi il n'est pas tenté de s'en inspirer, et donc fait un travail totalement original.
J'en conclu donc, à moins de totalement virer le code du contributeur sans le remplacer, qu'il est préférable de garder les noms des contributeurs dans le copyright. Une autre solution possible est aussi de demander aux contributeurs concernés par la réécriture ou les changements sur leur code, si ils acceptent d'abandonner leur copyright sur le nouveau code. Mais pas simple à faire (surtout sur du vieux code).
Il est dit qu'il faut indiquer la mention de copyright avec la/les années de publications, et la liste de toutes les personnes qui ont contribué au code ex : Copyright 2006-2016 Toto, Titi, Tata. Et sur chaque fichier du programme.
Par contre, il n'est pas précisé si on doit garder ou si on peut enlever la mention de copyright conçernant une personne pour laquelle sa contribution n'est plus présente dans le code… Ça ne répond pas trop à ma question :-/
Dans le projet en question, ajouter les contributeurs dans l'entête de chaque fichier était une habitude qui avait été prise. Probablement (mes souvenirs sont vagues), parce que, au début du projet A (2001), d'une part, mise à part la compréhension des 4 libertés fondamentales du libre, on ne maitrisait peut être pas très bien l'aspect juridique de la LGPL (pas sûr de tout maîtriser encore aujourd'hui, d'où ma question :-) ), d'autres parts, on utilisait CVS à l'époque, et que bon, manipuler ce truc n'était particulièrement pas user friendly pour inspecter l'historique etc (par rapport aux outils d'aujourd'hui).. Et souvent on intégrait des patchs à la main, donc les commits n'étaient pas créés par les auteurs des patchs. Ça nous permettait donc de laisser au moins une trace de qui avait touché à quel fichier, et de le savoir sans avoir à utiliser CVS… (ce qui au final est encore utile aujourd'hui, étant donné que le dépôt CVS et subversion du projet A a disparu :-/ )
À l'ère d'outils comme Git, Github, Gitlab, il est clair que l'intérêt de faire perdurer cette pratique est moins pertinente.
Dans le cas d'un changement de licence, retirer le code des contributeurs qui ne se sont pas manifesté, ne veut pas dire modifier l'historique de git. Je ne pense pas que dans le cas de VLC, il s'agisse de modifier la licence des versions passées, mais celle des versions à venir. Cela veut donc juste dire que le code source, à la date D où sa licence change, il n'y a plus de lignes de code "litigieuses".
"Bonjour madame. Alors 54,50 € s'il vous plait. Ah. Attendez. Je n'ai plus de connexion internet. La caisse ne veux plus encaisser. Désolé. Pouvez-vous revenir plus tard ? (grmlmlml faut encore que je rappel "internet by Orange")
C'est con à dire, c'est facile à dire, mais je ne vois que cette solution.
Contribuer au code. Contribuer au code en résolvant les problèmes qui te semble les plus importants. Contribuer en faisant de la pub, du prosélitisme. Contribuer en faisant du triage de bug. Contribuer en informant des bugs sur bugzilla. Contribuer en votant pour des features sur bugzilla. Contribuer en utilisant simplement Firefox (pour faire monter les stats des utilisateurs). Contribuer en traduisant les sites, la doc, l'interface, le support etc. Contribuer en installant firefox sur les ordinateurs des gens, sur leurs téléphones. Contribuer en développant des extensions innovantes. Contribuer en notifiant les propriétaires de sites web que leur site est à la ramasse sur Firefox. Contribuer en lançant une campagne de pub en 4x3 dans le métro (pour ceux qui ont gagné au loto :-)).
La liste n'est pas exhaustive. Et d'ailleurs cette liste est valable pour n'importe quel logiciel libre : il faut contribuer d'une manière ou d'une autre. Pas besoin d'être un développeur.
J'utilise qwant depuis plus d'un an. J'ai quasi abandonné Google. Je n'y retourne que de très rare fois quand vraiment les réponses de qwant ne me satisfont pas (à vue de nez, 5% de mes recherches).
Bref, je trouve Qwant particulièrement bon. Si Google est meilleur (ou en tout cas te parait meilleur), c'est en parti parce qu'il t'a pisté comme un malade et qu'il sort des réponses en fonction de ton "profil". (qui ne sont pas forcément les plus pertinentes, puisque Google choisi pour toi ce qui est pertinent selon lui).
Personnellement, je n'ai pas besoin d'études en tout genre pour voir et pour dire que, oui, en informatique, ou plus précisément dans le développement logiciel (puisque c'est mon domaine), il y a beaucoup moins de filles que de garçons.
Depuis plus de 16 ans que je bosse, chez de multiples clients et sociétés, j'en ai vu des open-spaces rempli de développeurs/euses ou des équipes de développeurs/euses . J'ai aussi fait cours à des étudiants en info à la fac jusqu'à il y a 2 ans.
Le constat a toujours été le même : il y a une écrasante majorité de garçon. J'aurais même tendance à dire qu'il y a de moins en moins de filles (surtout si je compare à mes études il y a +20 ans en IUT info ou Miage).
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.
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 ?
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 ;-)
Pourquoi ce manque ? Ou c'est moi qui confond des extensions de SpiderMonkey avec le standard ?
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.
Oui d'ailleurs, je doute que dans 50 ans on ait autant de voitures de collection datant de ces dix dernières années, que de voitures de collection de maintenant.
Les voitures de collections d'aujourd'hui (qui ont donc 30 ans et +) n'ont quasiment pas d’électronique. Il est "simple" de rénover ces voitures. Il "suffit" de réusiner/refabriquer les pièces manquantes ("simple" et "suffit" pour dire que ce n'est pas impossible, même si ça demande un savoir faire, du travail et du matériel). Quoique pour les pièces plastiques, c'est un peu plus compliqué à reproduire j'imagine (faut des moules, tout ça..)
Par contre, pour refaire une carte électronique comme celles utilisées dans les voitures d'aujourd'hui, avec le microcode et cie des différentes puces (sans parler des ordinateurs du tableau de bord qui pilotent les tablettes embarquées, les GPS et cie), je me demande si ça sera vraiment faisable dans 30 ans quand on n'aura plus la technologie ou les sources ou mêmes des images binaires des systèmes embarqués… Sauf si certains ont déjà pensé à ça, et piratent les ordinateurs embarqués de leur voiture préférés pour en extraire les ROMS afin de pouvoir les réutiliser plus tards (au pire dans des émulateurs), à la manière des ROMS de nos vieilles consoles/vieux ordinateurs des années 80 :-)
Sinon, je ne connais pas la taille exacte de l'équipe de développement, mais mon petit doigt me dit qu'elle n'est probablement pas suffisante pour les "side-projects" voulus :
Est-ce que ça veut dire que personne n'a pensé au projet dans son ensemble avant d'aller dans son éditeur de code préféré ?
J'aime bien ta naïveté :-) Depuis quand il y a de la doc sur des projets open-source fraichement démarrés ? _^ (ouai on n'est pas vendredi, je sais).
J'ai comme l'impression que tu n'as pas vécu, voir tu n'étais pas encore né, un certain 5 octobre 1991, sinon tu te serais tout autant plaint ;-)
Sinon je te recommande la lecture des livres de Tanenbaum, peut être que ça aidera à comprendre le fonctionnement de cet OS (ou pas, déjà faudrait comprendre le Rust, que je ne connais pas vraiment).
[^] # Re: Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2.
Pourquoi faudrait-il leur attribuer la paternité du code d'un fichier quand leurs contributions n'y sont plus ?
Pour l'historique, il y a les mentions de copyright dans les versions précédentes, le dépôt de code etc..
# Un début de réponse
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 4.
Bon, finalement, j'ai fini par envoyé un mail à la FSF pour leur demander leur avis.
Et la réponse est… qu'il n'y a pas de réponse simple.
Comme je le pensais, selon la personne qui m'a répondu, il peut être très compliqué de déterminer si le code enlevé ou encore, si du code refondu peut avoir encore des "traces" ou pas du code original. J'imagine qu'il entend par là que le code refondu, même si syntaxiquement il n'est plus le même, peut faire tout de même la même chose ou très inspiré du code original. (la logique globale, ou l'idée générale de l'algo peut rester la même). Et dans ce cas, le contributeur reste plus ou moins l'auteur du code refondu.
Il m'a indiqué aussi que dans certaines boites, quand ils veulent refondre quelque chose et en être l'unique détenteur du copyright, ils font appel à quelqu'un qui n'a jamais vu le code original. Ainsi il n'est pas tenté de s'en inspirer, et donc fait un travail totalement original.
J'en conclu donc, à moins de totalement virer le code du contributeur sans le remplacer, qu'il est préférable de garder les noms des contributeurs dans le copyright. Une autre solution possible est aussi de demander aux contributeurs concernés par la réécriture ou les changements sur leur code, si ils acceptent d'abandonner leur copyright sur le nouveau code. Mais pas simple à faire (surtout sur du vieux code).
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2. Dernière modification le 26 mai 2016 à 16:25.
J'ai fait quelques recherches et je suis tombé sur le "mode d'emploi" de la GPL/LGPL/AGPL.
Il est dit qu'il faut indiquer la mention de copyright avec la/les années de publications, et la liste de toutes les personnes qui ont contribué au code ex : Copyright 2006-2016 Toto, Titi, Tata. Et sur chaque fichier du programme.
Par contre, il n'est pas précisé si on doit garder ou si on peut enlever la mention de copyright conçernant une personne pour laquelle sa contribution n'est plus présente dans le code… Ça ne répond pas trop à ma question :-/
[^] # Re: Copyleft
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 2. Dernière modification le 26 mai 2016 à 16:01.
Dans le projet en question, ajouter les contributeurs dans l'entête de chaque fichier était une habitude qui avait été prise. Probablement (mes souvenirs sont vagues), parce que, au début du projet A (2001), d'une part, mise à part la compréhension des 4 libertés fondamentales du libre, on ne maitrisait peut être pas très bien l'aspect juridique de la LGPL (pas sûr de tout maîtriser encore aujourd'hui, d'où ma question :-) ), d'autres parts, on utilisait CVS à l'époque, et que bon, manipuler ce truc n'était particulièrement pas user friendly pour inspecter l'historique etc (par rapport aux outils d'aujourd'hui).. Et souvent on intégrait des patchs à la main, donc les commits n'étaient pas créés par les auteurs des patchs. Ça nous permettait donc de laisser au moins une trace de qui avait touché à quel fichier, et de le savoir sans avoir à utiliser CVS… (ce qui au final est encore utile aujourd'hui, étant donné que le dépôt CVS et subversion du projet A a disparu :-/ )
À l'ère d'outils comme Git, Github, Gitlab, il est clair que l'intérêt de faire perdurer cette pratique est moins pertinente.
[^] # Re: Cas VLC
Posté par Laurent J (site web personnel, Mastodon) . En réponse au message Copyright du code d'un fork refondu. Évalué à 5.
Dans le cas d'un changement de licence, retirer le code des contributeurs qui ne se sont pas manifesté, ne veut pas dire modifier l'historique de git. Je ne pense pas que dans le cas de VLC, il s'agisse de modifier la licence des versions passées, mais celle des versions à venir. Cela veut donc juste dire que le code source, à la date D où sa licence change, il n'y a plus de lignes de code "litigieuses".
[^] # Re: blockchain
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 7.
"Bonjour madame. Alors 54,50 € s'il vous plait. Ah. Attendez. Je n'ai plus de connexion internet. La caisse ne veux plus encaisser. Désolé. Pouvez-vous revenir plus tard ? (grmlmlml faut encore que je rappel "internet by Orange")
[^] # Re: javascript ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 2.
Ça tombe bien, dans les derniers Chrome, Firefox et Nodejs, tu peux utiliser les classes sans faire du typescript ;-)
[^] # Re: Le javascript
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Node.js passe la sixième vitesse. Évalué à 3. Dernière modification le 13 mai 2016 à 17:16.
Ouai mais avec PHP, je n'ai pas besoin d'une ferme de 15 serveurs octocore pour servir une appli normale à 15 utilisateurs. #vendredi
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 0.
Le gars qui se plaint d'un manque d'une fonctionnalité tout en affirmant qu'il n'a pas cherché si la fonctionnalité existait. Très fort.
Indice : FAQ.
[^] # Re: Non.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Il faut sauver le soldat Firefox!. Évalué à 5.
En contribuant.
C'est con à dire, c'est facile à dire, mais je ne vois que cette solution.
Contribuer au code. Contribuer au code en résolvant les problèmes qui te semble les plus importants. Contribuer en faisant de la pub, du prosélitisme. Contribuer en faisant du triage de bug. Contribuer en informant des bugs sur bugzilla. Contribuer en votant pour des features sur bugzilla. Contribuer en utilisant simplement Firefox (pour faire monter les stats des utilisateurs). Contribuer en traduisant les sites, la doc, l'interface, le support etc. Contribuer en installant firefox sur les ordinateurs des gens, sur leurs téléphones. Contribuer en développant des extensions innovantes. Contribuer en notifiant les propriétaires de sites web que leur site est à la ramasse sur Firefox. Contribuer en lançant une campagne de pub en 4x3 dans le métro (pour ceux qui ont gagné au loto :-)).
La liste n'est pas exhaustive. Et d'ailleurs cette liste est valable pour n'importe quel logiciel libre : il faut contribuer d'une manière ou d'une autre. Pas besoin d'être un développeur.
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 4.
Et ne pas oublier la version lite https://lite.qwant.com/ , pour ceux qui trouvent l'interface par défaut trop lourde ;-)
[^] # Re: Autres OS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Android: position dominante et navigateurs alternatifs. Évalué à 3.
J'utilise qwant depuis plus d'un an. J'ai quasi abandonné Google. Je n'y retourne que de très rare fois quand vraiment les réponses de qwant ne me satisfont pas (à vue de nez, 5% de mes recherches).
Bref, je trouve Qwant particulièrement bon. Si Google est meilleur (ou en tout cas te parait meilleur), c'est en parti parce qu'il t'a pisté comme un malade et qu'il sort des réponses en fonction de ton "profil". (qui ne sont pas forcément les plus pertinentes, puisque Google choisi pour toi ce qui est pertinent selon lui).
[^] # Re: Linux for desktop !!!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 2.
Comme Mozilla pour Firefox.
C'est pour cela (entre autres raisons) que j'utilise le Firefox vanilla, et non pas celui de la distro
[^] # Re: Le logiciel libre, c’est repenser la société
Posté par Laurent J (site web personnel, Mastodon) . En réponse au sondage Pour ou contre le hors sujet sur LinuxFr.org ?. Évalué à 2.
Personnellement, je n'ai pas besoin d'études en tout genre pour voir et pour dire que, oui, en informatique, ou plus précisément dans le développement logiciel (puisque c'est mon domaine), il y a beaucoup moins de filles que de garçons.
Depuis plus de 16 ans que je bosse, chez de multiples clients et sociétés, j'en ai vu des open-spaces rempli de développeurs/euses ou des équipes de développeurs/euses . J'ai aussi fait cours à des étudiants en info à la fac jusqu'à il y a 2 ans.
Le constat a toujours été le même : il y a une écrasante majorité de garçon. J'aurais même tendance à dire qu'il y a de moins en moins de filles (surtout si je compare à mes études il y a +20 ans en IUT info ou Miage).
# developpement : idem
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 10.
J'ai rencontré et eu connaissance de cas similaires pour des prestations de développement :
Et c'est une grande satisfaction quand tu apprend que le projet a eu du retard, que cela ne correspond pas à ce que voulait le client etc…
On en a que pour son argent.
# GNU/Windows
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Bash dans Windows. Évalué à 10.
lu sur twitter
:-)
[^] # Re: Trollons
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. É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 Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. É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: Autres exemples rigolos
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. É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: Dépendances
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. É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
[^] # Re: Dépendances
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. É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: Trollons
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 2.
Il y a des paquets npm qui nécessitent une compilation ?
[^] # Re: L’obsolescence programmée n’existe pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal L'increvable. Évalué à 6.
Oui d'ailleurs, je doute que dans 50 ans on ait autant de voitures de collection datant de ces dix dernières années, que de voitures de collection de maintenant.
Les voitures de collections d'aujourd'hui (qui ont donc 30 ans et +) n'ont quasiment pas d’électronique. Il est "simple" de rénover ces voitures. Il "suffit" de réusiner/refabriquer les pièces manquantes ("simple" et "suffit" pour dire que ce n'est pas impossible, même si ça demande un savoir faire, du travail et du matériel). Quoique pour les pièces plastiques, c'est un peu plus compliqué à reproduire j'imagine (faut des moules, tout ça..)
Par contre, pour refaire une carte électronique comme celles utilisées dans les voitures d'aujourd'hui, avec le microcode et cie des différentes puces (sans parler des ordinateurs du tableau de bord qui pilotent les tablettes embarquées, les GPS et cie), je me demande si ça sera vraiment faisable dans 30 ans quand on n'aura plus la technologie ou les sources ou mêmes des images binaires des systèmes embarqués… Sauf si certains ont déjà pensé à ça, et piratent les ordinateurs embarqués de leur voiture préférés pour en extraire les ROMS afin de pouvoir les réutiliser plus tards (au pire dans des émulateurs), à la manière des ROMS de nos vieilles consoles/vieux ordinateurs des années 80 :-)
[^] # Re: Ce n'est pas vendredi, mais...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Redox OS. Évalué à 6.
Comme Linux a sa naissance quoi ;-)
[^] # Re: Ça semble si bien, et pourtant…
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Redox OS. Évalué à 9.
J'aime bien ta naïveté :-) Depuis quand il y a de la doc sur des projets open-source fraichement démarrés ? _^ (ouai on n'est pas vendredi, je sais).
J'ai comme l'impression que tu n'as pas vécu, voir tu n'étais pas encore né, un certain 5 octobre 1991, sinon tu te serais tout autant plaint ;-)
Sinon je te recommande la lecture des livres de Tanenbaum, peut être que ça aidera à comprendre le fonctionnement de cet OS (ou pas, déjà faudrait comprendre le Rust, que je ne connais pas vraiment).