d'auditer un minimum pour éviter d'introduire un truc potentiellement dangereux
Je suis désolé mais s'il n'audite que les .service il ne va pas auditer grand chose. Ce ne sont que des fichiers purement descriptifs. La seule chose à auditer s'il veut auditer quelquechose c'est systemd en lui même.
Par contre je suis d'accord qu'une fois audité, ça le sera pour tous les services l'utilisant, tout comme ce serait le cas si la LSB était plus riche, et son utilisation plus systématique. Par exemple la quasi totalité des fonctions en préambule du script init cité, en particulier celle vérifiant que le programme ayant le PID stocké dans le PIDFile soit bien le bon programme (le reproche fait par Misc plus bas) est tout à fait générique et aurait sa place dans une library.
Ce que je veux dire, c'est que dans ce cas, ton audit se dirigera uniquement sur les scripts n'utilisant pas délibérément la "library", mais pour que ce soit viable sa non-utilisation devra être limitée et justifiée par les mainteneurs. Tu conserveras la flexibilité de pouvoir en tant que non mainteneur modifier à volonté un script en particulier si ça te chante, tout ayant une base commune riche, stable et "auditée".
Oui mais rien n'empêche de mutualiser du code shell comme c'est déjà le cas avec LSB. Ensuite pour que la comparaison de Xavier Claude soit valable, il faut qu'il compare le code C de systemd lié au lancement/séquencement + la configuration du service avec le script init shell.
Après l'avantage d'un code shell mutualisé shell, c'est que tu peux choisir de l'utiliser … ou pas ! Une simple ligne de commentaire et hop ! C'est l'avantage d'être une library plutôt que le coeur de ton system. Alors que dans la cas de systemd si tu veux modifier légèrement le comportement d'un lancement, pour un seul démon, parce que t'es dans un cas particulier ou que tu veux tester quelquchose … bah tu peux pas. Tu dois te plier au plus petit dénominateur commun, qui je l'accorde va fonctionner dans 95% des cas, mais qui ne va pas te permettre de gérer à ta sauce même de manière temporaire.
Pour finir, le seul avantage que je voyais à sytemd c'est la gestion fine de l'ordonnancement des démons/tâches grâce à une synchro DBus. Mais malheureusement si même ça c'est pas encore au point à la vue de ce qui et décrit plus haut sur autofs … alors pour l'instant en temps qu'adminsys je sens que je vais être plus embêter qu'autre chose par cette migration forcée.
Après si au final, on est tous d'accord sur le fait qu'aucun mot français ne convienne à la traduction du mot anglais library dans le contexte qui est le notre, on arrête d'essayer de chercher on adopte le mot anglais et puis on en parle plus. Ce ne sera pas le premier et encore moins le dernier.
A priori je ne connais pas d'autres cas où on ait adopté un faux-ami (et oui c'est ce que c'est!) comme traduction, simplement parce que … parce que quoi d'ailleurs ? Parce que ça sonne presque pareil alors ça doit vouloir dire la même chose ?
Euh dans un script sysvinit fait consciencieusement et dans les règles de l'art, un sourcing des fichiers de conf (/etc et/ou /etc/default whatelse?) est fait au début du script : la configuration est séparée du script et c'est heureux.
Après je dois avoir passé trop de temps à faire du shell au lieu de tripoter du systemd, mais je trouve vraiment rien de sorcier à lire/écrire du script shell. Surtout que dans la majorité des cas ça revient à faire toujours à peu près la même chose au détail près du démon lancé qui change : un chargement des fichiers de conf, un parsing des arguments, un gros switch case pour les traiter. La complexité reste dans le code du démon lancé heureusement !
Bon à un peu plus de 30 piges et 15 ans de GNU/Linux et autres Unices, je sens déjà plus le vieux croûton que la miche qui sort du four… Monde cruel !
Sur ce, m'en vais retourner à mon havane … ça suit des lois d'évolution beaucoup plus lente (même si il y aurait à redire mais ce serait complètement HS).
Entièrement d'accord, ça enlèverait définitivement la connotation au livre qui me semble infondée.
"Collection" met déjà plus en avant la cohérence du contenu visant à rendre un service dans un domaine donné.
De mon côté j'avais pensé à "boîte à outils", même si ça n'exprime pas forcement tout ce qu'est une "library" : un code "métier" qui rend un service + une API pour l'utiliser.
Mais bon moi même qui suis très à cheval sur la langue ça m'arrive de fourcher de temps à temps, les mauvaises habitudes orales vont de toutes les façons être très dures à tordre… il n'y a qu'à voir comment il est compliqué et long de faire corriger un enfant de 3 ans qui vient à peine d'assimiler un nouveau mot mais avec un défaut de prononciation. Là on parle de peut-être 3 à 4 décennies de mauvaises habitudes linguistiques de toute une communauté, relayé par l'enseignement qui plus est !
Il y a de fortes chances que ta "message box" soit de l'AJAX.
Et le principal problème c'est que tu ne vas pas a priori (dans la limite de mes connaissances) pouvoir émettre du XMPP par ton browser (pour des raisons de sécurité).
Tu as en fait 2 choix :
- Soit en effet utiliser BOSH pour encapsuler le XMPP dans du HTTP (c'est un peu raccourci mais c'est l'idée).
- Soit tu devras développer toi même un combo AJAX/serveur, et la partie serveur devra alors faire office de proxy XMPP (s'enregistrer sur le serveur XMPP, envoyer les messages…). Je ne connais qu'une seule solution qui utilise cette technique et donc n'utilise pas le BOSH entre le browser et le serveur : Salut à Toi.
A priori le plus simple sera plutôt la première solution qui semble la plus utilisée en ce moment, et dont l'intégration reste relativement simple. Un framework javascript du style converse.js associé à un proxy BOSH de type punjab fera très bien l'affaire.
Pas le temps de fournir les liens vers les différents logiciels (libre par ailleurs), mais ton moteur de recherche préféré fera très bien le travail à ma place :P
En conclusion, il semblerait qu'il faille éviter à tout prix d'utiliser du SVG avec Firefox, canvas a des performances largement supérieures à la fois avec Firefox et Chromium
Ca ne m'étonnerait pas que linuxfr reçoivent une autre mise en demeure de l'avocat de la W3C pour denigrement d'un format qu'elle a mise tant de temps à normaliser, ou alors de la fondation Mozilla pour avoir pointé du doigt son incompétence à intégrer un format d'image … trollomètre … top départ !
Jobscheduler est plutôt pas mal sur le papier, mais en pratique c'est pas la même : doc assez exhaustive pour le niveau mais très fouillie et ça manque d'exemples de plus grande envergure. Ensuite il maque en agent 64bits, qui est en cours de préparation depuis février selon le dev en interface chez sos-berlin, mais pour l'instant rien. J'ai proposé mon aide, et je me suis intéressé aux problèmes rencontrés lors du portage : pas de réponse.
Un autre point c'est le manque de visibilité, et l'aspect communautaire un peu difficile à comprendre : le SCM n'est pas accessible même en anonymous, donc on ne peut pas vraiment participer au dev, ni même suivre les développements en cours.
Donc affaire à suivre, et en effet dans la sphère du libre, a priori il y a encore un créneau à prendre en ce qui concerne les schedulers multi-plateformes (dans le sens d'une tâche composée de plusieurs sous-tâches distribuées sur des machines différentes et coordonnées par un élément central).
Le truc qui fait que (pour moi) jobscheduler n'a pas la maturité pour une mise en production "professionnelle", c'est l'absence d'agent en 64 bits. Il n'y a que scheduler principal, et encore tronqué de pas mal de fonctionnalités (pas de wrapping perl par ex). J'ai proposé mon aide au dev de Gmbh(sos-berlin) qui est en interface, mais pour l'instant pas de réponse depuis février (il m'a répondu sur d'autres points, mais pas sur l'éventualité de mon aide ni d'une date de release). Une autre chose qui limite l'aspect libre et surtout communautaire, est que l'on a pas accès à leur SCM directement, les sources ne sont accessibles que via un tarball au moment de la release …
Donc non, il n'existe pas encore de scheduler multi-plateforme digne de ce nom dans la sphère libre.
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 1.
Xavier Claude parlait je cite
Je suis désolé mais s'il n'audite que les .service il ne va pas auditer grand chose. Ce ne sont que des fichiers purement descriptifs. La seule chose à auditer s'il veut auditer quelquechose c'est systemd en lui même.
Par contre je suis d'accord qu'une fois audité, ça le sera pour tous les services l'utilisant, tout comme ce serait le cas si la LSB était plus riche, et son utilisation plus systématique. Par exemple la quasi totalité des fonctions en préambule du script init cité, en particulier celle vérifiant que le programme ayant le PID stocké dans le PIDFile soit bien le bon programme (le reproche fait par Misc plus bas) est tout à fait générique et aurait sa place dans une library.
Ce que je veux dire, c'est que dans ce cas, ton audit se dirigera uniquement sur les scripts n'utilisant pas délibérément la "library", mais pour que ce soit viable sa non-utilisation devra être limitée et justifiée par les mainteneurs. Tu conserveras la flexibilité de pouvoir en tant que non mainteneur modifier à volonté un script en particulier si ça te chante, tout ayant une base commune riche, stable et "auditée".
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 5.
Oui mais rien n'empêche de mutualiser du code shell comme c'est déjà le cas avec LSB. Ensuite pour que la comparaison de Xavier Claude soit valable, il faut qu'il compare le code C de systemd lié au lancement/séquencement + la configuration du service avec le script init shell.
Après l'avantage d'un code shell mutualisé shell, c'est que tu peux choisir de l'utiliser … ou pas ! Une simple ligne de commentaire et hop ! C'est l'avantage d'être une library plutôt que le coeur de ton system. Alors que dans la cas de systemd si tu veux modifier légèrement le comportement d'un lancement, pour un seul démon, parce que t'es dans un cas particulier ou que tu veux tester quelquchose … bah tu peux pas. Tu dois te plier au plus petit dénominateur commun, qui je l'accorde va fonctionner dans 95% des cas, mais qui ne va pas te permettre de gérer à ta sauce même de manière temporaire.
Pour finir, le seul avantage que je voyais à sytemd c'est la gestion fine de l'ordonnancement des démons/tâches grâce à une synchro DBus. Mais malheureusement si même ça c'est pas encore au point à la vue de ce qui et décrit plus haut sur autofs … alors pour l'instant en temps qu'adminsys je sens que je vais être plus embêter qu'autre chose par cette migration forcée.
[^] # Re: pour une fois pour toute !
Posté par ZeDuke . En réponse au journal Reportlab 3.1.8. Évalué à 2.
Je plussoie devnewton et Jarvis.
Après si au final, on est tous d'accord sur le fait qu'aucun mot français ne convienne à la traduction du mot anglais library dans le contexte qui est le notre, on arrête d'essayer de chercher on adopte le mot anglais et puis on en parle plus. Ce ne sera pas le premier et encore moins le dernier.
A priori je ne connais pas d'autres cas où on ait adopté un faux-ami (et oui c'est ce que c'est!) comme traduction, simplement parce que … parce que quoi d'ailleurs ? Parce que ça sonne presque pareil alors ça doit vouloir dire la même chose ?
Bon j'arrête je sens l'agonie monter en moi :P
[^] # Re: If it works, don't fix it.
Posté par ZeDuke . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 2.
Euh dans un script sysvinit fait consciencieusement et dans les règles de l'art, un sourcing des fichiers de conf (/etc et/ou /etc/default whatelse?) est fait au début du script : la configuration est séparée du script et c'est heureux.
Après je dois avoir passé trop de temps à faire du shell au lieu de tripoter du systemd, mais je trouve vraiment rien de sorcier à lire/écrire du script shell. Surtout que dans la majorité des cas ça revient à faire toujours à peu près la même chose au détail près du démon lancé qui change : un chargement des fichiers de conf, un parsing des arguments, un gros switch case pour les traiter. La complexité reste dans le code du démon lancé heureusement !
Bon à un peu plus de 30 piges et 15 ans de GNU/Linux et autres Unices, je sens déjà plus le vieux croûton que la miche qui sort du four… Monde cruel !
Sur ce, m'en vais retourner à mon havane … ça suit des lois d'évolution beaucoup plus lente (même si il y aurait à redire mais ce serait complètement HS).
[^] # Re: Prudence
Posté par ZeDuke . En réponse au journal Un clone de la Raspberry Pi avec réseau 1 Gb et port SATA. Évalué à 1.
gros doigts … grosse … paire de gants :P
[^] # Re: pour une fois pour toute !
Posté par ZeDuke . En réponse au journal Reportlab 3.1.8. Évalué à 1.
Entièrement d'accord, ça enlèverait définitivement la connotation au livre qui me semble infondée.
"Collection" met déjà plus en avant la cohérence du contenu visant à rendre un service dans un domaine donné.
De mon côté j'avais pensé à "boîte à outils", même si ça n'exprime pas forcement tout ce qu'est une "library" : un code "métier" qui rend un service + une API pour l'utiliser.
Mais bon moi même qui suis très à cheval sur la langue ça m'arrive de fourcher de temps à temps, les mauvaises habitudes orales vont de toutes les façons être très dures à tordre… il n'y a qu'à voir comment il est compliqué et long de faire corriger un enfant de 3 ans qui vient à peine d'assimiler un nouveau mot mais avec un défaut de prononciation. Là on parle de peut-être 3 à 4 décennies de mauvaises habitudes linguistiques de toute une communauté, relayé par l'enseignement qui plus est !
# Les vues de bind9
Posté par ZeDuke . En réponse au message Dnsmasq local et global. Évalué à 1.
Bind9 gère les vues : en fonction d'un critère, par exemple l'IP source du demandeur, tu peux associer un fichier de déclaration de zone différent.
Un exemple de mise en place
[^] # Re: le jour ou on blâmera le marteau
Posté par ZeDuke . En réponse au journal Un bug inhumain. Évalué à 0.
Ou comme disait un certain Confucius : "Ce n'est pas le vin qui enivre, c'est l'homme qui s'enivre"
[^] # Re: BOSH
Posté par ZeDuke . En réponse au message Intégration web chat / XMPP. Évalué à 0.
Il y a de fortes chances que ta "message box" soit de l'AJAX.
Et le principal problème c'est que tu ne vas pas a priori (dans la limite de mes connaissances) pouvoir émettre du XMPP par ton browser (pour des raisons de sécurité).
Tu as en fait 2 choix :
- Soit en effet utiliser BOSH pour encapsuler le XMPP dans du HTTP (c'est un peu raccourci mais c'est l'idée).
- Soit tu devras développer toi même un combo AJAX/serveur, et la partie serveur devra alors faire office de proxy XMPP (s'enregistrer sur le serveur XMPP, envoyer les messages…). Je ne connais qu'une seule solution qui utilise cette technique et donc n'utilise pas le BOSH entre le browser et le serveur : Salut à Toi.
A priori le plus simple sera plutôt la première solution qui semble la plus utilisée en ce moment, et dont l'intégration reste relativement simple. Un framework javascript du style converse.js associé à un proxy BOSH de type punjab fera très bien l'affaire.
Pas le temps de fournir les liens vers les différents logiciels (libre par ailleurs), mais ton moteur de recherche préféré fera très bien le travail à ma place :P
[^] # Re: Ca, c'est fait
Posté par ZeDuke . En réponse au journal Option "Do Not Track" de Firefox et sites de la Mozilla Foundation. Évalué à 4.
J'aime pas ta traque … boom !
# Attention au dénigrement publique !
Posté par ZeDuke . En réponse au journal Dans lequel on revient sur les performances SVG des Firefox. Évalué à 9.
Ca ne m'étonnerait pas que linuxfr reçoivent une autre mise en demeure de l'avocat de la W3C pour denigrement d'un format qu'elle a mise tant de temps à normaliser, ou alors de la fondation Mozilla pour avoir pointé du doigt son incompétence à intégrer un format d'image … trollomètre … top départ !
[^] # Jobscheduler : oui mais ....
Posté par ZeDuke . En réponse à la dépêche Shinken 1.4. Évalué à 1.
Jobscheduler est plutôt pas mal sur le papier, mais en pratique c'est pas la même : doc assez exhaustive pour le niveau mais très fouillie et ça manque d'exemples de plus grande envergure. Ensuite il maque en agent 64bits, qui est en cours de préparation depuis février selon le dev en interface chez sos-berlin, mais pour l'instant rien. J'ai proposé mon aide, et je me suis intéressé aux problèmes rencontrés lors du portage : pas de réponse.
Un autre point c'est le manque de visibilité, et l'aspect communautaire un peu difficile à comprendre : le SCM n'est pas accessible même en anonymous, donc on ne peut pas vraiment participer au dev, ni même suivre les développements en cours.
Donc affaire à suivre, et en effet dans la sphère du libre, a priori il y a encore un créneau à prendre en ce qui concerne les schedulers multi-plateformes (dans le sens d'une tâche composée de plusieurs sous-tâches distribuées sur des machines différentes et coordonnées par un élément central).
[^] # Re: Oui c'est cela !
Posté par ZeDuke . En réponse à la dépêche Shinken 1.4. Évalué à 1.
Le truc qui fait que (pour moi) jobscheduler n'a pas la maturité pour une mise en production "professionnelle", c'est l'absence d'agent en 64 bits. Il n'y a que scheduler principal, et encore tronqué de pas mal de fonctionnalités (pas de wrapping perl par ex). J'ai proposé mon aide au dev de Gmbh(sos-berlin) qui est en interface, mais pour l'instant pas de réponse depuis février (il m'a répondu sur d'autres points, mais pas sur l'éventualité de mon aide ni d'une date de release). Une autre chose qui limite l'aspect libre et surtout communautaire, est que l'on a pas accès à leur SCM directement, les sources ne sont accessibles que via un tarball au moment de la release …
Donc non, il n'existe pas encore de scheduler multi-plateforme digne de ce nom dans la sphère libre.