Marc Balmer ne semble partager que le nom de famille avec Steve. Je ne saurais dire s'il est fou ou si c'est un génie. Il cherche actuellement à pouvoir scripter des éléments de configuration système.
Il voudrait, par exemple, écrire dans un fichier de configuration que les paramètres se trouvent dans tel annuaire ou dans telle base de données, via quelques commandes. Au lieu d'écrire :
password = "secret"on pourrait écrire :password = MySecuredSQL.query("Select password from CMDB where software = 'MySoft';")Il semble avoir retenu le langage Lua avec soin. Il a souligné ses différents avantages dans ce cadre d'utilisation :
- Faible empreinte mémoire (< 128k)
- Rapidité d'exécution
- Syntaxe simple, facile à apprendre, tout en restant puissante
- Facilité de liaison avec le langage C
- Facilité d'isolation (sandboxing)
Ce projet ne date pas d'hier, la première annonce a été faite en octobre 2009. Il a été jugé suffisamment intéressant par Google pour qu'il puisse bénéficier d'un GSoC sur l'intégration Noyau.
Il y a quelques mois, il a intégré Lua dans le cœur du système NetBSD. Il a présenté des exemples de code en C permettant d'exécuter du Lua ou d'exporter des fonctions en Lua. Il a également montré l'inverse, du Lua vers le C. Il faut bien reconnaître que la glue nécessaire est assez simple à mettre en œuvre.
L'avenir nous dira si ce genre de système se démocratisera dans des systèmes bénéficiant d'une plus grande audience. Les possibilités offertes semblent aussi effrayantes qu'attirantes, tant elles sont nombreuses.
# "tant elles sont nombreuses"
Posté par Dorian . Évalué à 8.
Mais encore ? Et puis, on peut déjà le faire, surtout le fichier de conf utilise un format standard (.ini, .xml, .yml, …) en faisant un script externe.
D'accord cette méthode là est mieux, mais j'y vois surtout une grosse source de bugs… et une surcouche complexe au dessus des fichiers de conf.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: "tant elles sont nombreuses"
Posté par Batchyx . Évalué à 4.
Pour avoir une floppée de scripts externes pour gérer ma config réseau compliquée, je parle en connaissance de cause.
Personnellement, j'aimerai bien pouvoir modifier par exemple les serveurs SMTP et les proxies à utiliser avec ce genre de méthode. Ça serait certainement plus fiable et plus automatisé que ce que je fais déjà.
# Deja fait
Posté par pasBill pasGates . Évalué à 0.
[^] # Re: Deja fait
Posté par nicolas . Évalué à -1.
Impossible de trouver le paquet « wmi ».
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.
nicolas:~% sudo aptitude install windows
Impossible de trouver le paquet « windows ».
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.
Il n’est pas dans les dépôts, ils sont où les sources que je puisse compiler ?
[^] # Re: Deja fait
Posté par pasBill pasGates . Évalué à 0.
Comme quoi Linux a encore des choses a faire niveau standards :+)
[^] # Re: Deja fait
Posté par Ontologia (site web personnel) . Évalué à 3.
Windows a WMI ( qui est pas mal pour avoir eu à l'utiliser), et Unix le shell/perl/les outils.
C'est deux logique : langage unifié appelant des ressources vs ensemble d'outil à la philosophie KISS avec qq langages pour les faire danser entre eux.
Je préfère la seconde, mais la première se défend, elle est plus intégrée
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Deja fait
Posté par Fabimaru (site web personnel) . Évalué à 7.
- WMI est un système (personnellement que je trouve génial) qui permet de configurer un tas de programmes via des objets COM et du script
- ce qu'il veut, c'est que les fichiers de configuration exécutent du code pour obtenir leur contenu.
J'ai bien peur que tu sois à coté de la plaque
[^] # Re: Deja fait
Posté par pasBill pasGates . Évalué à -1.
Et c'est exactement ce que WMI fait (avec le bonus qu'il fait ca sur un domaine entier)
[^] # Re: Deja fait
Posté par Fabimaru (site web personnel) . Évalué à 3.
Non. Il veut que son application aille chercher sa config ailleurs, de manière scriptable. Il ne veut pas qu'un tier accède à la config du programme
Quand je lis son exemple, ça me laisse à penser qu'il pourrait vouloir aller la chercher n'importe où (par exemple grace à une requette HTTP).
[^] # Re: Deja fait
Posté par pasBill pasGates . Évalué à -2.
[^] # Re: Deja fait
Posté par Fabimaru (site web personnel) . Évalué à 2.
# Génial !
Posté par Jerome Herman . Évalué à 6.
J'ai vraiment du mal à voir l'interet qu'il peut y avoir à foutre un parseur XML et un interpreteur LUA (même si ils sont tout petits) dans un serveur qui n'a au final rien à foutre de l'un ou de l'autre (au hasard un MDA).
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
N.B : j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
[^] # Re: Génial !
Posté par helkyn . Évalué à 10.
Ce que veut faire Marc est de proposer des modules permettant de contrôler la configuration du base system NetBSD via des modules Lua.
Les objectifs sont, entre autres:
1 - les API C actuellement présentes sont déjà très exhaustives en elles mêmes, et fournissent la majorité des fonctionnalités. Ce qu'il manque, ce sont des wrappers qui permettent de les exploiter dans des programmes avec des langages plus haut niveau.
Pour quelle raison? Une toute bête: scripter de la conf, sous Unix, ca se fait en shell/perl/python/ruby (suivant les affinités des individus...) à grands coups de pipes, popen(), execution de sed/awk/sh/grep/cat qui font que ca en devient bordélique, en plus de pousser à l'erreur. Qui ici vérifie proprement les codes d'erreurs retournés par system() quand il fait ces scripts? En toute honnêteté? Et qui ne se plaint pas quand la regexp de pexpect pète parce que dans la dernière version, "P" est devenu "p"?
Cela permet de pouvoir toucher à des configs clients et d'en déployer/rapporter/modifier facilement, à l'instar de WMI de Windows ou des plist MacOSX.
2 - pour Lunatik (un interpréteur Lua in kernel), et de façon plus générale, Lua+C, cela permet de fournir un environnement plus sûr que ce que donne le C et ses pointeurs. C'est pas comme si le jeu de ces dernières années était de retourner un kernel X ou Y en jouant sur des assignations à NULL ou des débordements de toute sorte, ou d'avoir un parsing de chaînes/octets moisi qui finit avec un exploit.
Il souhaite aussi voir ce que ça donne pour kauth(9), ce qui permettrait (pour l'instant, en théorie) de fournir un environnement pour construire ses propres modèles de sécu avec une vision développeur, plutôt qu'intégrateur (comme SELinux par exemple). Aujourd'hui, c'est C ou rien, ce qui pose un problème quand on développe des moniteurs de référence [1]...
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Quant au reste, le principe d'une interface bien conçue, c'est justement d'éviter cela. C'est pas comme si NetBSD avait accumulé une grosse expérience la dedans avec ses couches d'émulation et de compatibilité binaire depuis 15 ans.
j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
C'est un exemple pour montrer un concept... La chose en est à peine à la conception qu'il faudrait déjà se taper les discussions sur la sémantique et l'implémentation détaillée.
[1] http://en.wikipedia.org/wiki/Reference_monitor
[^] # Re: Génial !
Posté par Jerome Herman . Évalué à 3.
Je suis BSDiste. J'utilise principalement FreeBSD et OpenBSD (donc je connais moins bien NetBSD), mais je peux te dire que le basesys ne prend pas en charge les configuration avancées de type :
- Changement de MDA/MTA
- Authentification LDAP pour tout le monde (virtuel, réel etc. sauf root/wheel)
- Modification profonde de la config de base des Bases de données (genre load balancing, changement des réglages de moteurs de base de données, outils d'instrumentations intégrés etc.)
- PHP (oui PHP c'est juste l'horreur à suivre au niveau packages, avec des dépendances à tous les étages etc.)
Bref tout çà pour dire que même si j'ai une grosse confiance en les devs BSD, je ne vois pas comment leur projet de script peut ne pas partir en vrille au bout d'un moment.
Sous Linux ça a pris environ cinq ans (2004-2009 à peu près) pour que des éléments simple de config (genre les modes supportés par le serveur X) deviennent inéditables/inmodifiables parceque des scripts qui génèrent des scripts qui génèrent des scripts viennent t'écraser ta config à chaque mise à jour, voire à chaque reboot/fermeture violente de l'appli.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
[^] # Re: Génial !
Posté par helkyn . Évalué à 4.
Il n'est pas question d'avoir un fourre tout pour que Mr X, qui préfère exim, ait un module Lua qui lui permettra de configurer Postfix avec la magie LDAP. Non.
Vois ca comme ça: pour créer un utilisateur sous Unix, il est quasiment obligatoire de repasser par useradd(8). Si derrière, l'objectif est de faire un script python, qui au final, va appeler une pelle de commandes shell, le python n'a aucun d'intérêt, à part faire de la glue. Et quand il ne sait pas faire, on est coincé.
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.
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.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp. Quand tu en auras marre de vomir à chaque ligne (entre les #ifdef__LINUX_VERSION_2.6__ && !__LINUX_VERSION_2.4__, les strncmp() dans TOUS les sens pour afficher les points de montage, les options de compil qui ont été activées on ne sait trop comment (merci les autodaubes!), j'espère que tu verras.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
Personne n'obligera à les utiliser.
Il faut bien admettre que la tendance va vers cela, et qu'il n'y a pas beaucoup d'alternatives quand on veut passer à l'échelle (sauf à faire du cfengine/puppet, ce qui revient, au final, à créer des scripts de configuration automagiques... ou jouer avec kickstart -- aïe -- , même joueur joue encore).
PS: que je sache, l'outil omniprésent par excellence sous Unix, le shell, a son comportement contrôlé par un script shell lui même, non (.profile, .*rc, ...)? Ca n'a pas l'air d'avoir dérangé plus que ça ces 30 dernières années.
[^] # Re: Génial !
Posté par Jerome Herman . É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.
[^] # Re: Génial !
Posté par helkyn . É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 .
[^] # Re: Génial !
Posté par Jerome Herman . Évalué à 3.
Oui mais généralement il appellent quand même des fonctions shell au final, comme tu le faisais remarquer. Et pour peu qu'on sache un peu lire du code, même si on ne comprend pas les fonctions shell appelées, on arrive généralement à recomposer le script avec un minimum d'effort.
Avec une forte intégration POSIX au millieu, ca devient beaucoup plus complexe. Déjà il faut passer par l'étape programmation pour immiter le comportement, et ensuite il faut comprendre véritablement ce qui se passe sous peine de se ramasser à l'execution.
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.
Sur un script perl imbitable, ou sur un script python imbitable on arrive toujours à savoir ce qui se passe en remplaçant une execution shell par un echo vers fichier. C'est long et casse pied, mais pas à pas on finit par avoir la liste des commandes que le script veut passer.
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.
STOP. Le projet consiste à mettre dans le système de base NetBSD un iterpreteur LUA avec une forte intégration au système POSIX sous jacent. C'est pas une hypothèse que je fais sur un coup de tête, c'est le but du projet.
Les exemples donnés par le créateur du projet sont la refonte du système d'install, la modification des scripts d'init et le changement d'option du client DHCP. J'invente rien, c'est écrit noir sur blanc dans les deux liens donnés dans le journal.
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...
Si le système d'install et les scripts d'init passent en LUA, ce qui une fois de plus est le but annoncé du projet, je ne vois pas comment je pourrais me passer d'apprendre LUA pour pouvoir mettre les mains dans le camboui. Or il se trouve que mettre les mains dans le camboui c'est mon métier.
Quels points forts?
Le monde Unix effectue traditionellement la séparation des droits au niveau fichier, le monde windows le fait au niveau interface.
Dans les deux cas il y a des avantages et des défauts.
Sous Unix le défaut est que pour faire fonctionner un système complexe il faut donner des droits dans tous les sens, avec des serveurs qui se lancent en root puis abandonnent progressivement leurs privilèges.
Sous windows le défaut est que pour faire fonctionner un système complexe il faut installer et lier whatdouzemille framework même si au final on se sert de 10% des possibilités des frameworks concernés.
Sous Unix l'avantage est que les configs, scripts et autre conneries sont déplaceables et maléables à volonté. Une fois qu'on a une config qui marche, on a la quasi certitude qu'elle va marcher sous tout un tas de système raisonnablement posix. Et on peut le déplacer de droite à gauche sans trop de soucis.
Sous windows l'avantage est l'intégration. Vu qu'on ramasse tout un bloc de fonctions d'un coup on a au moins la certitude qu'on ne va pas avoir à se retourner le crane si un jour on a besoin d'ajouter ou d'enlever une fonctionnalité.Et au moins on a pas à se prendre la tête pour savoir comment tout çà va dialoguer ensemble.
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
Oui. Enfin bon faut pas dire çà aux banques, assurances, instituts de recherche et autres systèmes experts.
[^] # Re: Génial !
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: Génial !
Posté par Christophe Discours (site web personnel) . Évalué à 1.
# Des avantages et des problèmes..
Posté par chimrod (site web personnel) . Évalué à 7.
Pour les avantages, c'est tout simplement génial ! Lua est très bien intégré pour chacune des deux applications, et permet de modifier tellement de choses que c'en devient un plaisir d'en modifier le comportement par défaut.
Lua est un langage facile à comprendre, et quand les idées ne manquent pas, il est plus facile de se lancer dans un développement en lua qu'en C, avant le faire partager avec l'upstream. La séparation entre la configuration de l'appli et l'appli elle même n'existe plus, et on commence très vite à mettre les mains dans le cambouis pour adapter l'appli à ce que l'on souhaite.
Le problème est que la gestion d'erreur est assez mal intégrée : une erreur de syntaxe et l'ensemble du script n'est pas exécuté : bon courage pour aller débugger un fichier de conf !
Même chose si l'api lua fourni par l'application change. Awesome s'est calmé maintenant, mais je continue de croiser les doigts à chaque mise à jour en espérant que ma configuration fonctionnera toujours et que je n'aurais pas à passer une heure ou deux à tout corriger.
Le diff est de rigueur après chaque mise à jour entre la configuration par défaut, et celle actuelle, et devient plus pénible à chaque fois que la configuration évolue.
Je pense que ce principe de scripter les applis doit se limiter aux applications principales (les trois que j'utilise le permettant sont mon navigateur de texte, le gestionnaire de fenêtre.. et mon éditeur de texte), sinon ça devient vite le bordel. Tout dépend du temps qu'on est prêt à passer à configurer son outil.
Bien sûr rien n'oblige à mettre le doigt dans l'engrenage, mais une fois qu'on a commencé à adapter l'outil pour notre utilisation à nous, c'est dur de revenir au comportement par défaut !
[^] # Re: Des avantages et des problèmes..
Posté par téthis . Évalué à 4.
Il y a un backtrace fourni par LUA, ainsi qu'une API de debugage. Il faut, bien évidement, que le programme affiche l'état de la pile afin qu'on connaisse le contexte de l'erreur. Un « simple » fichier de configuration ne devrait pas poser de problème là dessus
http://www.lua.org/manual/5.1/manual.html#3.8
Le problème de LUA est que, par défaut, le langage est trop laxiste (c'est parfois un avantage) et qu'une simple erreur de typo fout le boxon. Les solutions pour éviter l'accès aux variables non déclarées existent.
http://thomaslauer.com/comp/LuaStrict et http://lua-users.org/wiki/DetectingUndefinedVariables
Cela rend quand même la chose plus complexe.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
[^] # Re: Des avantages et des problèmes..
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
En plus il n'y a pas (à ma connaissance) de débogueur correct pour du code embarqué dans un programme C.
Il faut donc se méfier de son apparente simplicité.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Marrant
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Marrant
Posté par DLFP est mort . Évalué à 4.
Quand un logiciel accepte des directives « include » c'est sympa, quand il accepte des directives « include shell » (lancer un programme et inclure sa sortie) c'est mieux, et quand c'est carrément un langage de programmation c'est bandant.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Marrant
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Marrant
Posté par barmic . Évalué à 3.
Il est possible de créer des interfaces graphiques pour ce genre de choses de la même manière que pour créer des filtres dans les lecteurs de mails (si ceci, je fais cela), c'est plus limité mais c'est possible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Marrant
Posté par DLFP est mort . Évalué à 2.
Par exemple, mes fichiers de config sont versionnés, indentés et commentés, comme du code quoi.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Marrant
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Marrant
Posté par Thomas Douillard . Évalué à 2.
parameter = affiche_la_gui();
} ?
# Beotien sans doute
Posté par Misc (site web personnel) . Évalué à 7.
Est ce que l'idée est de faire la requête à chaque fois ( exemple dans le cas du password que tu donnes, lors de l'utilisation du mot de passe ) ?
Ou la faire juste au démarrage de l'application ( auquel cas je pense que les outils comme puppet le font déjà, toute fois en renversant par défaut l'ordre, à savoir que si on change le mot de passe, le soft est relancé ( si on fait bien son manifest, bien sur ).
J'ai un peu du mal, juste à partir du journal, à voir ce qu'on ne peut pas déjà faire de façon externe, ni un véritable usage. Des fichiers de configurations en script, ça existe déjà ( comprendre "des fichiers de configuration en shell, en perl, ou en python" ), et j'ai pas le sentiment que ça soit révolutionnaire.
[^] # Re: Beotien sans doute
Posté par helkyn . Évalué à 1.
# offlineimap
Posté par 태 (site web personnel) . Évalué à 3.
[^] # Re: offlineimap
Posté par Xavier Maillard . Évalué à 1.
[^] # Re: offlineimap
Posté par 태 (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.