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.
Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Mais on va pas refaire le monde à coup de "chez moi, moi je".
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.)
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
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é.
Que dalle. Pour créer des comptes Kerberos, gérer un déport du contexte (ou même l'initialiser), soit c'est la magie PAM (donc, solution externe à Python, qui fait justement ce dont je parle), soit faire des os.system("ksu ") avec du pexpect partout. Moche, surtout quand il s'agit de créer des contextes sur un serveur Web (dans les endroits un peu sérieux ou mettre un dn + mdp associé dans un fichier à part pour faire des bind() n'est pas accepté).
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.
C'est le cas.
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.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
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.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
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.
Quels points forts?
La pluralité des API, avec les environnements Linux qui réinventent/changent la roue tous les ans? Ou peut-être les 300 syscalls associés?
Des kernels qui font 20MiB ("small is beautiful", hein?)
Le choix d'avoir voulu externaliser la gestion du graphisme en dehors de l'OS (serveur X), et où maintenant les redites niveau gestion affichage (tty, pseudo tty, console...) sont éloquentes?
Un outil pour une tâche, avec des administrateurs actuels qui lancent python/perl/irb à la première occasion suivant affinité ("when all you have is a hammer, everything looks like a nail")
Le "tout est fichier"...
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
C'était à une époque ou les kernels ne faisaient pas dans les 20MiB l'image, où les API étaient simples mais pauvres, où l'usage/l'exploitation du système était reservé à une certaine élite et ne requérait pas le support de fonctionnalités très évoluées.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 3.
Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Mais on va pas refaire le monde à coup de "chez moi, moi je".
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.)
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
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é.
Que dalle. Pour créer des comptes Kerberos, gérer un déport du contexte (ou même l'initialiser), soit c'est la magie PAM (donc, solution externe à Python, qui fait justement ce dont je parle), soit faire des os.system("ksu ") avec du pexpect partout. Moche, surtout quand il s'agit de créer des contextes sur un serveur Web (dans les endroits un peu sérieux ou mettre un dn + mdp associé dans un fichier à part pour faire des bind() n'est pas accepté).
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.
C'est le cas.
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.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
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.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
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.
Quels points forts?
La pluralité des API, avec les environnements Linux qui réinventent/changent la roue tous les ans? Ou peut-être les 300 syscalls associés?
Des kernels qui font 20MiB ("small is beautiful", hein?)
Le choix d'avoir voulu externaliser la gestion du graphisme en dehors de l'OS (serveur X), et où maintenant les redites niveau gestion affichage (tty, pseudo tty, console...) sont éloquentes?
Un outil pour une tâche, avec des administrateurs actuels qui lancent python/perl/irb à la première occasion suivant affinité ("when all you have is a hammer, everything looks like a nail")
Le "tout est fichier"...
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
C'était à une époque ou les kernels ne faisaient pas dans les 20MiB l'image, où les API étaient simples mais pauvres, où l'usage/l'exploitation du système était reservé à une certaine élite et ne requérait pas le support de fonctionnalités très évoluées.
Pour une argumentation que je rejoins totalement: voir celle de David (Chisnall) http://www.informit.com/articles/article.aspx?p=424451 .