rendre le système de démarrage plus efficace serait possible en utilisant un démon de démarrage capable de parallèliser le lancement des scripts systèmes
si on en croit la personne qui a travaillé sur le projet SoC pour l'amélioration de la vitesse de boot de debian ( http://bootdebian.blogspot.com/ ) , le gain en parallèlisant les scripts est très faible (environ 4s ).
optimiser l'exécution des scripts systèmes serait possible en utilisant par exemple Zsh à l'intérieur des scripts systèmes, comme indiqué dans l'article, afin de limiter les appels systèmes.
Ce qui prend surtout du temps (AMA) c'est tout simplement l'exécution du service en lui même, le service qui peut avoir à lire des fichiers de configurations, checker des données, etc ...
dépendance supplémentaire : cela obligerait à installer Zsh sur tous les systèmes utilisant ces scripts optimisés, en plus du shell par défaut
c'est pas vraiment un argument, zsh doit peser à peine 500 ko, sachant que dans les paquets de base d'une majeure partie, tu as perl qui por une installation minimal te prendra beaucoup plus de place.
les scripts systèmes utilisant le langage de script Zsh ne seraient plus compatibles POSIX, ce qui consisterait à un recul en matière de standardisation des systèmes Unix
c'est indéniable, ceci dit, quand on voit upstart qui sera un espèce de démon fourre tout (init, cron, udev, inetd?) où on rompt avec la tradition "faire une chose, mais la faire correctement", on peut très bien envisagé de faire une rupture complète et essayer de faire un des scripts d'init en zsh avec une bibliothèque de fonction zsh pour remplacer les outils tels que sed, cut, grep, awk. C'est une idée mais ça peut être intéressant si les résultats sont là.
maintenance : les scripts (ba)sh ne sont peut-être pas optimisés, mais ils ont l'intêret d'être compris par l'ensemble des personnes ayant des connaissances en scripting. Combien de personnes connaissent le langage de script de Zsh
si on raisonne comme ça, on serait toujours à faire du basic, après si les dev ne veulent pas évoluer, apprendre de nouvelles choses, je ne donne pas cher de leur avenir dans l'informatique dans 10 ans au train où ça évolue. Après, zsh à une doc et comme signalé dans l'article il y'a des wiki, des listes de diffusions, des canaux irc, etc ...
migration : passer à Zsh nécessiterait de réécrire tous les scripts systèmes pour utiliser des fonctions Zsh et bénéficier des gains de performancespas insurmontable à mon avis...
Et pour les scripts non systèmes mais nécessitant un interprêteur efficace et un langage plus évolué que (ba)sh, des langages tels que Perl, Python ou Ruby me semblent plus adaptés.
je suis pas d'accord, je suis utilisateur des langages de scripts (non shell) que tu sites et il est à mon avis souvent bien plus rapide d'utiliser un script shell pour certains tâches.
[^] # Re: De l'utilisation de Zsh dans les scripts systèmes...
Posté par kolter (site web personnel, Mastodon) . En réponse à la dépêche À la (re)découverte de Zsh. Évalué à 3.
si on en croit la personne qui a travaillé sur le projet SoC pour l'amélioration de la vitesse de boot de debian ( http://bootdebian.blogspot.com/ ) , le gain en parallèlisant les scripts est très faible (environ 4s ).
optimiser l'exécution des scripts systèmes serait possible en utilisant par exemple Zsh à l'intérieur des scripts systèmes, comme indiqué dans l'article, afin de limiter les appels systèmes.
Ce qui prend surtout du temps (AMA) c'est tout simplement l'exécution du service en lui même, le service qui peut avoir à lire des fichiers de configurations, checker des données, etc ...
dépendance supplémentaire : cela obligerait à installer Zsh sur tous les systèmes utilisant ces scripts optimisés, en plus du shell par défaut
c'est pas vraiment un argument, zsh doit peser à peine 500 ko, sachant que dans les paquets de base d'une majeure partie, tu as perl qui por une installation minimal te prendra beaucoup plus de place.
les scripts systèmes utilisant le langage de script Zsh ne seraient plus compatibles POSIX, ce qui consisterait à un recul en matière de standardisation des systèmes Unix
c'est indéniable, ceci dit, quand on voit upstart qui sera un espèce de démon fourre tout (init, cron, udev, inetd?) où on rompt avec la tradition "faire une chose, mais la faire correctement", on peut très bien envisagé de faire une rupture complète et essayer de faire un des scripts d'init en zsh avec une bibliothèque de fonction zsh pour remplacer les outils tels que sed, cut, grep, awk. C'est une idée mais ça peut être intéressant si les résultats sont là.
maintenance : les scripts (ba)sh ne sont peut-être pas optimisés, mais ils ont l'intêret d'être compris par l'ensemble des personnes ayant des connaissances en scripting. Combien de personnes connaissent le langage de script de Zsh
si on raisonne comme ça, on serait toujours à faire du basic, après si les dev ne veulent pas évoluer, apprendre de nouvelles choses, je ne donne pas cher de leur avenir dans l'informatique dans 10 ans au train où ça évolue. Après, zsh à une doc et comme signalé dans l'article il y'a des wiki, des listes de diffusions, des canaux irc, etc ...
migration : passer à Zsh nécessiterait de réécrire tous les scripts systèmes pour utiliser des fonctions Zsh et bénéficier des gains de performancespas insurmontable à mon avis...
Et pour les scripts non systèmes mais nécessitant un interprêteur efficace et un langage plus évolué que (ba)sh, des langages tels que Perl, Python ou Ruby me semblent plus adaptés.
je suis pas d'accord, je suis utilisateur des langages de scripts (non shell) que tu sites et il est à mon avis souvent bien plus rapide d'utiliser un script shell pour certains tâches.
M.