Justement.
Il y a une plus grosse base de code perl dans le coeur de mon système (debian) que, par exemple, python. Quelqu'un a mentionné ruby, plus haut: idem.
A tel point que l'interpréteur perl est required (sur debian) mais j'ai eu de nombreux systèmes parfaitement fonctionnels sans python ni ruby ou autres.
Du coup, ça ne serait pas, justement, les gens qui utilisent ces langages qui n'en font qu'à leur tête?
Ton argument est, justement, en faveur des langages qui sont arrivés les premiers...
python3-minimal: 5 dépendances (je "déplie" libpython hein), ~10megs installé, à noter que je n'ai pas encore vu de paquet python utiliser le minimal, hein, a chaque fois en pratique il y a une chiée de trucs qui arrivent avec...
Ce que je veux dire, c'est que rien qu'en théorie, perl gagne sur le nombre de paquets et l'espace disque occupés. En théorie, python est comparable, mais en pratique je n'ai pas souvenir d'avoir vu une seule application python ne pas dépendre des paquets plus complets. Je sais que de nos jours, quelques megs de stockage ne font pas une grande différence dans l'immense majorité des cas, mais le fait d'avoir moins de paquets installés, ça permets de pouvoir plus facilement lire les changelogs de tous les paquets lors des mises à jour. Et ça, je pense que c'est important, d'un point de vue sécurité.
Toujours sur une Debian, ou perl est requis, se concentrer sur perl ou dash pour automatiser ça implique qu'il n'y a pas besoin d'installer d'autres interpréteurs, ce qui réduit la surface d'attaque.
Et vu que tu parles d'automatisation, avant qu'on ne me demande "comment on gère le parc", je dirais que pour éviter un nouvel interpréteur, toujours sur une debian, je vois:
drist, en shell posix
rexify, en perl
cfengine3, en C
Seul cfengine3 dispose d'un système d'agents, par contre (pour un outil codé dans l'un de ces langages. Je peux me tromper) ce qui implique que les systèmes peuvent se mettre au propre d'eux mêmes, quand ils ont le temps et l'accès au réseau (l'air de rien, l'accès constant au réseau etre loin d'être aussi garanti qu'on ne le pense, il suffit de voir les équipements de rue qui peuvent être placés dans des endroits ou ça ne capte pas, par exemple. Je ne parle pas juste de mémé dans son coin perdu ou c'est a peine si le téléphone cuivre passe).
A ma connaissance, il existe de nombreux autres outils de gestion de conf, qui eux, sont en ruby ou python principalement, donc c'est vrai qu'il y a de très, très grandes chances que de toute façon python ou ruby soient installés.
Mon propos n'est pas de nier une réalité (dans la plupart des cas, il y aura un truc plus connu de nos jours que perl d'installé) mais bien de rappeler qu'il est très possible que perl5 soit justement la façon de faire au sein d'une industrie, puisqu'il est la depuis très longtemps (je n'ai pas souvenir d'avoir utilisé debian basée sur perl4, ni même embarquer les deux... pour python, no comment) et a une belle assise dans nos systèmes actuels. A moins de considérer debian comme négligeable :) (plutôt utilisé par des petites boîtes il paraît).
A noter que je ne code ni en python, ni en ruby, ni en perl, donc je ne sais pas ce que ces langages valent en terme de perf.
[^] # Re: Vraie question
Posté par freem . En réponse au lien why PERL is still relevant in 2022?. Évalué à 10. Dernière modification le 15 juillet 2022 à 09:36.
Justement.
Il y a une plus grosse base de code perl dans le coeur de mon système (debian) que, par exemple, python. Quelqu'un a mentionné ruby, plus haut: idem.
A tel point que l'interpréteur perl est required (sur debian) mais j'ai eu de nombreux systèmes parfaitement fonctionnels sans python ni ruby ou autres.
Du coup, ça ne serait pas, justement, les gens qui utilisent ces langages qui n'en font qu'à leur tête?
Ton argument est, justement, en faveur des langages qui sont arrivés les premiers...
Ah oui. Et aussi...
Ce que je veux dire, c'est que rien qu'en théorie, perl gagne sur le nombre de paquets et l'espace disque occupés. En théorie, python est comparable, mais en pratique je n'ai pas souvenir d'avoir vu une seule application python ne pas dépendre des paquets plus complets. Je sais que de nos jours, quelques megs de stockage ne font pas une grande différence dans l'immense majorité des cas, mais le fait d'avoir moins de paquets installés, ça permets de pouvoir plus facilement lire les changelogs de tous les paquets lors des mises à jour. Et ça, je pense que c'est important, d'un point de vue sécurité.
Toujours sur une Debian, ou perl est requis, se concentrer sur perl ou dash pour automatiser ça implique qu'il n'y a pas besoin d'installer d'autres interpréteurs, ce qui réduit la surface d'attaque.
Et vu que tu parles d'automatisation, avant qu'on ne me demande "comment on gère le parc", je dirais que pour éviter un nouvel interpréteur, toujours sur une debian, je vois:
Seul cfengine3 dispose d'un système d'agents, par contre (pour un outil codé dans l'un de ces langages. Je peux me tromper) ce qui implique que les systèmes peuvent se mettre au propre d'eux mêmes, quand ils ont le temps et l'accès au réseau (l'air de rien, l'accès constant au réseau etre loin d'être aussi garanti qu'on ne le pense, il suffit de voir les équipements de rue qui peuvent être placés dans des endroits ou ça ne capte pas, par exemple. Je ne parle pas juste de mémé dans son coin perdu ou c'est a peine si le téléphone cuivre passe).
A ma connaissance, il existe de nombreux autres outils de gestion de conf, qui eux, sont en ruby ou python principalement, donc c'est vrai qu'il y a de très, très grandes chances que de toute façon python ou ruby soient installés.
Mon propos n'est pas de nier une réalité (dans la plupart des cas, il y aura un truc plus connu de nos jours que perl d'installé) mais bien de rappeler qu'il est très possible que perl5 soit justement la façon de faire au sein d'une industrie, puisqu'il est la depuis très longtemps (je n'ai pas souvenir d'avoir utilisé debian basée sur perl4, ni même embarquer les deux... pour python, no comment) et a une belle assise dans nos systèmes actuels. A moins de considérer debian comme négligeable :) (plutôt utilisé par des petites boîtes il paraît).
A noter que je ne code ni en python, ni en ruby, ni en perl, donc je ne sais pas ce que ces langages valent en terme de perf.