C'est amusant, tout ce que tu cites comme des défauts sont pour moi des qualités et réciproquement.
Par exemple le script Python qui ne fait "que" glue. Ca veut dire que si je ne veux pas de python sur ma machine, il suffit dans 90% des cas de faire du copier coller les éléments shell pour passer le script à la main.
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Bref tout çà à analyser pour pouvoir passer sereinement quatre lignes de scripts...
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Alors ca tu vois c'est EXACTEMENT ce qui fait que je ne veux pas de Lua dans mon BSD. Si Aujourd'hui j'ai un truc qui tombe tous les jours à 19h dans mon système et qui me fait chier (et bien oui, dans la vraie vie on a pas toujours installé les serveurs qu'on maintient), ben je vais dans le cron, je le tue et fin de l'histoire. Si demain ce truc peut être n'importe ou dans mon système, éventuellement régénéré par tel ou tel serveur si je le détruis, je vais devenir dingue.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp.
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Personne n'obligera à les utiliser.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Il faut bien admettre que la tendance va vers cela
Oui, tout le monde veut copier le système windows/mac avec du call-back reporting dans tous les sens SAUF QUE traditionellement Unix/BSD/Linux sont monolithiques avec une logique de séparation et que NT/OS X sont des micro-kernel avec une logique de bloc.
Rien ne m'empêche sous Linux de prendre 300 API différentes au sein du même programme et de donner mes droits aux utilisateurs device par device, par contre sous windows, avec les objets COM par exemple, j'ai soit accès au bloc API ou pas, et si il y a des limitations elles sont gérés par le bloc, fonction par fonction, et pas par le système lui même. Par contre je peux me brosser pour faire tourner en même temps IIS 6.0 avec .net 2.0 et IIS 7.0 avec .net 3.5
(N.B : je sais que l'on peut faire du bloc en unix et faire tourner 14 IIs en même temps sous windows, mais c'est pas vraiment la philosophie du truc)
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.
[^] # Re: Génial !
Posté par Jerome Herman . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 6.
Par exemple le script Python qui ne fait "que" glue. Ca veut dire que si je ne veux pas de python sur ma machine, il suffit dans 90% des cas de faire du copier coller les éléments shell pour passer le script à la main.
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Bref tout çà à analyser pour pouvoir passer sereinement quatre lignes de scripts...
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Alors ca tu vois c'est EXACTEMENT ce qui fait que je ne veux pas de Lua dans mon BSD. Si Aujourd'hui j'ai un truc qui tombe tous les jours à 19h dans mon système et qui me fait chier (et bien oui, dans la vraie vie on a pas toujours installé les serveurs qu'on maintient), ben je vais dans le cron, je le tue et fin de l'histoire. Si demain ce truc peut être n'importe ou dans mon système, éventuellement régénéré par tel ou tel serveur si je le détruis, je vais devenir dingue.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp.
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Personne n'obligera à les utiliser.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Il faut bien admettre que la tendance va vers cela
Oui, tout le monde veut copier le système windows/mac avec du call-back reporting dans tous les sens SAUF QUE traditionellement Unix/BSD/Linux sont monolithiques avec une logique de séparation et que NT/OS X sont des micro-kernel avec une logique de bloc.
Rien ne m'empêche sous Linux de prendre 300 API différentes au sein du même programme et de donner mes droits aux utilisateurs device par device, par contre sous windows, avec les objets COM par exemple, j'ai soit accès au bloc API ou pas, et si il y a des limitations elles sont gérés par le bloc, fonction par fonction, et pas par le système lui même. Par contre je peux me brosser pour faire tourner en même temps IIS 6.0 avec .net 2.0 et IIS 7.0 avec .net 3.5
(N.B : je sais que l'on peut faire du bloc en unix et faire tourner 14 IIs en même temps sous windows, mais c'est pas vraiment la philosophie du truc)
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.