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 ;-)
[^] # 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 ;-)