Oui mais à la limite je ne suis pas contre justement. Si j'ai toujours accès après aux sources pour améliorer la version communautaire ça ne me pose pas de soucis de ne pas diriger le projet en fait.
Par contre s'il souhaite juste prendre le projet sans moi, bah il peut s'il passe en GPLv2 (mais même en AGPL non?) en effet. reste à voir ce qu'il en fait ensuite en fait. S'il traite le code comme il est en train de le faire du projet open source, là je serai assez contre.
Bref, si je peux garder la AGPL pour que les utilisateurs aient un maximum de droit, je préfère bien sûr.
Ce qui me dérange n'est pas qu'il cherche à rentabiliser son outil. C'est même son droit le plus total. Non, ce qui me dérange est comment il s'y prends : en utilisant la communauté comme un simple argument marketing, et en orientant le développement vers sa solution privatrice, sans rien retourner au moteur initial.
C'est un modèle Open Core. C'est légal, mais pas très moral sachant que la communauté a été la première force de Nagios.
De plus jusqu'à maintenant Shinken avait pour vocation de réintégrer Nagios, même si son auteur l'aurait utilisé pour sa solution privatrice. Mais au moins la communauté pouvait encore le faire évoluer. En effet, les propositions d'évolutions sur Nagios ne sont pas écoutées. Ceci pose un léger soucis.
Faire un lien avec Icinga pourquoi pas, je discute beaucoup avec eux ces temps-ci en effet. Reste à voir comment se ferra un tel rapprochement. L'aspect <techniquement compatible> c'est facile, en majorité déjà fait même si Shinken propose des notions de haut niveau pas encore fournies par Icinga web (leur module web, principale force d'Icinga).
Par contre je ne chercherai pas à me couper d'autres partenaires comme Centreon par exemple. car j'adore Centreon que j'utilise tout de même tous les jours :)
J'ai pleinement conscience de la division des forces, c'est bien pour ça que je mettais ma fierté de côté et que je demandais une inclusion dans Nagios canal historique. Mais vu que ce n'est pas possible, je suis bien obligé de proposer un nouveau choix à la communauté. J'espère seulement proposé une migration si facile que ceci ne posera pas de problème à tous les administrateurs.
La version 0.2 de Shinken va justement être orientée vers l'industrialisation et la facilité de mise en place de l'outil. D'ailleurs ceux qui vont voir les sources doivent mieux s'y retrouver depuis le code de la semaine dernière.
Shinken devait être la solution pour Nagios afin de lutter efficacement contre Zenoss et Zabbix. J'espère qu'il le sera, et que ce ne sera qu'un simple nom de paquet à changer lors de la mise en place de notre cher outil de supervision.
Bon, il fallait s'y attendre un peu, j'ai eu une réponse officielle (enfin ça y ressemble bien) de la part de la société derrière Nagios par l'intermédiaire un post twitter de la directrice de communication http://twitter.com/motherofnagios
Si on oublie le message précédent qui lance encore un FUD sur la marque Nagios à propos du plus grand regroupement de la communauté allemande qui a eu lieu il y a quelques temps, on peut en tirer comme conclusion que, seedcamp étant là pour trouver les nouvelles idées pour le projet Nagios, Shinken n'a même pas le droit de présence (dommage, la communauté aurait peu être eu un avis différent qui sait) dans l'environnement Nagios.
Pas de chance, il est tout de même là.
Le projet Shinken ne va donc plus chercher à intégrer le projet Nagios, vu que ce dernier n'en veut pas. Je vais faire en sorte de garder une compatibilité maximale pour ceux qui souhaite migrer, mais on peut désormais considérer Shinken comme un Fork de Nagios à part entière.
Ah oui c'est vrai, mais revenir sur la syntaxe des exceptions en as fait que le code devient tout de suite moins joli. Je reconnais que ce n'est pas un critère de premier ordre, mais moi j'aime bien ne pas avoir à détourner le regard quand je regarde mon code :p
Si quelqu'un se lance dans une migration vers 2.5 pourquoi pas, mais bon, dès que debian sera passé à une Python un peu plus à jour, on pourra revenir à une version plus sympathique.
Par contre là on parle pour l'écosystème GNU/Linux. Quelqu'un sait quelles sont les versions de Python classiques (entrendre en standard) pour les autres Unix (genre les Unix dont les noms commencent par un A ou un H)?
En effet, je suis la même personne, mais Shinken était déjà en cours depuis bien avant le soucis de droit sur le nom nagios entre ex-nagios-fr.org et Nagios Enterprise.
Shinken n'est pas un projet renégat. Il est arrivé comme un proof of concept non public pendant plusieurs mois. Le but était à l'époque de corriger les bugs que j'avais vu dans Nagios lorsque j'ai rédigé un livre dessus. Il y avait des problèmes de conceptions lorsqu'on arrivait à vouloir monter des environnements distribués grosso-modo.
Déjà auteur de plusieurs patchs pour Nagios (même après le début de Shinken d'ailleurs), j'avais présenté ces idées en offlist, mais il me fallait des preuves du bien fondé de mes idées (Pool de process pour les performances, division des processus pour la partie distribution).
Toujours en off, j'ai développé le proof of concept et j'ai présenté les idées pour intégrations en C dans Nagios. Ce développement était donc purement technique. N'ayant aucune réponse j'ai continué le développement. Je suis arrivé à un point où il était plus facile de mettre dans le proof of concept ce qui manquait de Nagios, plutôt que de continuer à vouloir extraire les idées pour les porter en C.
Là j'ai encore proposé une idée, mais plus originale, toujours en off : inclure le code du proof of concept dans une branche de développement. Toujours sans réponses (c'est une habitude sur le projet Nagios...), je relance ma proposition sur la mailing list (décembre, soit plus de 6 mois après le début du code finalement).
Là les réactions ont étés vives, mais au moins il y a eu réaction! sauf de l'auteur par contre.
C'est après cette histoire qu'est arrivée celle entre nagios-fr.org et l'auteur de Nagios. Histoire qui ne portait d'ailleurs pas du tout sur Shinken, mais sur Icinga, autre Fork de Nagios, soutenu par une société allemande.
Je ne compte plus les mails que j'ai envoyé en off à l'auteur de Nagios avant et après la proposition sur la mailing list pour savoir ce qu'il en pensait, mais je dois tomber dans son filtre spam vu que je n'ai jamais eu une seule réponse.
Là encore j'essaie d'intégrer le projet Nagios officiel en participant au concours seedcamp alors que le projet Shinken est déjà bien parti et pourrait s'en passer. Et devinez quoi? Et bien oui, le concours est soumis à modération, et pour l'instant ma proposition n'est pas encore validée pour ce concours alors que d'autres le sont.
Il ne faut pas oublier que Shinken propose à l'heure actuelle des fonctionnalités qui ne devraient être présentes que dans quelques mois dans la version privatrice de Nagios. Ceci explique peut être cela après tout. Ça devient un peu politique, mais ce n'est pas pour me ravir, bien au contraire car je ne suis pas si doué que ça à ce petit jeu.
Hé bien ça tombe bien, voici l'appel en Python dans le code :
self.process = subprocess.Popen(shlex.split(self.command), stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
Je trouve le module subprocess bien plus pratique à utiliser que les vieux popen (qui sont de toute manière toujours présent) :)
Le journal en question n'était-il pas un pauvre troll qui a peur devant la montée en puissance de Python au cours de ces dernières années? Mais bon un troll reste un troll, il ne cherche pas à argumenter après tout.
En fait c'est déjà le cas pour la partie module du daemon broker qui fait l'export des données (par exemple en MySQL ou Oracle). Ce n'est pas encore documenté par contre, mais les exemples de modules sont très simples à comprendre.
Ce type de module devrait arriver dans les autres daemons également. On peut imaginer par exemple un module pour l'Arbiter, qui est chargé de lire la configuration, module qui lirait la configuration en base plutôt qu'en fichier plat par exemple.
Un autre exemple de module serait pour le daemon poller qui est chargé de lancer les sondes. Un module pourrait être un python embarqué comme il existe du Perl embarqué pour Nagios, ou bien un module natif NRPE qui aurait de meilleures performances que de faire un popen par exemple.
Mais pour ça, il faut que je définisse comment les modules sont intégrés à ces daemons. Je prends toute aide/expérience sur ce point, comme sur tous les autres d'ailleurs.
Ah? Je ne crois pas que mon avis sur Python ait tellement changé. Peut être que je me suis mal exprimé.
En fait le but de Shinken au début était exactement celui-là : faire un test rapide en Python, puis porter en C.
Mais en prenant un peu de recul face à la facilité de porter Nagios en Python je me suis demandé quel serait le meilleur langage pour Nagios justement. C'est un ordonnanceur (donc gérer des dates et temps) qui lance des sondes (popen sur un script ou exécutable) et qui réagit au résultat (autre popen).
Est-ce une problématique bas niveau? Je ne pense pas. Gérer le temps n'est pas un problème de calcul très violent, surtout en utilisant un peu de cache sur les calculs lourd (5 lignes...). Le popen? Et bien le module pour en Python est très efficace et pratique à utiliser.
Je ne dit pas que c'était une erreur de coder Nagios en C il y a 10ans, car c'était le meilleur compromis pour avoir une grosse communauté. Mais maintenant? Le Python s'est fortement démocratisé (il n'y a qu'à voir les stats du langage sur ohloh) et offre une maintenabilité bien supérieure au C, sans pourtant sacrifier les performances.
La migration est problématique, j'en ait conscience, et ce problème ne sera peu être jamais résolu que par une bête guerre de projet. Au pire j'échoue, mais le coup de pied au c%l du projet Nagios sera déjà ça de pris, car au moins désormais il avance un petit peu avec seedcamp par exemple.
Si maintenant quelqu'un pense le contraire et porte mes idées en C pour le cœur, je ne vais pas lui jeter les pierres, bien au contraire. Mais je ne ferai pas ce travail moi même tout simplement. Je sais qu'une partie de ce que j'ai proposé est en cours de réalisation depuis quelques temps (le pool de process). Mais ce n'est qu'une partie de ce que Shinken apporte. Et au vues du temps que ceci prends, je pense avoir raison de rester sur Python.
L'avenir nous dira qui a raison. Au pire, en cas d'échec de ma part, j'aurais fait bouger Nagios et je me serait bien marré en codant en Python.
Il ne fonctionne pas. Tout comme avec la version standard sur RedHat5 et assimilé. Mais même pour cette dernière, la mise en place de Python 2.6 est facile.
La résistance a été forte, c'est un fait. Le soutient aussi, même si moins affiché. Par contre une personne n'a jamais donnée son avis, que ce soit officiellement ou non : l'auteur de Nagios tout simplement. C'est l'occasion pour lui d'accepter ce qu'on lui offre. Il a presque tout à y gagner en fait. C'est pour ça qu'il y a des chances que ceci réussisse.
C'est en effet la AGPL qui s'applique (sauf pour la documentation récupéré de Nagios, donc GPLv2). En fait je me suis mis du point de vue client qui se voit surveillé par un prestataire qui utilise l'outil : c'est libre il le sait, mais il n'a pas accès au code utilisé pour le superviser si c'est du GPLv3 standard. Le client doit avoir accès à ça, d'où la AGPL.
Ensuite ce n'est pas rédhibitoire car ceci ne concerne que le coeur de l'application, pas les sondes de supervision. Hors dans la quasi totalité des cas, c'est elles qui font la vraie plus value du prestataire avec l'organisation qui va autour.
Ah oui pour la dépêche, je vais rédiger et surtout compléter un peu plus alors.
Le choix du Python est en fait une heureuse rencontre : je connaissais ce langage que j'apprécie beaucoup, et au début Shinken était un proof of concept pour Nagios, donc il me fallait un langage où on puisse coder vite (et bien), quitte à reporter le code en C plus tard dans Nagios.
Il s'est révélé ensuite qu'il était plus simple (et efficace) de terminer le proof of concept avec ce qui lui manquait de Nagios que le contraire.
Pour les performances en fait l'architecture permet d'avoir une distribution de la charge très facile, mais c'est surtout l'utilisation du module multiprocessing de Python >= 2.6 qui permet de gagner en performances tout simplement. Nagios passe une grande partie de son temps à forker/écrire des fichiers plats. Deux problèmes réglés avec ce module. D'où de meilleures performances tout simplement, pas de secret ici.
Par contre je n'ai pas compris les numéros entre crochets. Ce n'est pas la méthode habituelle pour les liens?
J'ai oublié le nom de code de cette première version : Anemic Alligator. Ceci représente bien le potentiel de l'outil, mais qui a encore besoin d'un peu de temps pour arriver à maturité.
Le libre a d'autres arguments (liberté de modifier, diffuser...), concentrez-vous sur ce qui fait la différence plutôt que d'argumenter sur des trucs que le proprio peut aussi bien faire!
Ah! Tu viens de résumer en une phrase tout l'article. Merci :)
Pas sûr que sortir cette argumentation fasse avancer la cause du libre hors des geeks.
Mais justement c'est ce point que tente de traiter l'article. Si tu ne te concentre que sur "ce qui marche et point barre" comme le fait l'open source, tu n'y arriveras que très difficilement (et pour l'instant clairement pas pour les end users). Car une telle méthode est juste inefficace.
C'est pour ça qu'il faut faire prendre conscience aux personnes de l'importance de leurs libertés. Être libre sera toujours plus coûteux en terme d'effort que le contraire.
Si tu arrives à convaincre, les personnes iront vers les solutions libres, qui de fait s'amélioreront. Si tu les attires avec une simple supériorité technique, ce gain ne sera pas durable, tu pourras oublier le cercle vertueux.
Peut être que l'on s'y prends mal pour expliquer le libre, et ça semble être le cas on dirait bien. Mais ça ne le rends pas moins important pour autant.
Les libertés c'est flou, il est plus percutant (donc efficace?) d'illustrer les effets de cette perte de liberté.
ensuite si tout ceci débouche sur aucune solution utilisable pour les utilisateurs, oui, il va y avoir un problème, mais c'est que le cercle vertueux aura eu un raté quelque part, qu'il faut identifier, et régler.
Et c'est la toute l'erreur : se tromper d'ennemi. Bon nombre de logiciels proprios jouent le jeu de l'inter-opérabilité, et aucun des arguments que tu avances n'est alors contre eux.
Mais alors on peut parler de privateur : un logiciel propriétaire (code fermé) mais qui joue l'ouverture ne sera pas aussi privateur qu'un code d'Apple par exemple.
Reste un point cependant : ok les données sont ouvertes (c'est un point clé), mais quid de savoir quelles transformations sont effectuées dessus par le logiciel? C'est moins critique je le reconnais, et tu peux toujours t'en sortir vu que tu as l'accès complet à tes données, mais si tu veux avoir cette liberté de savoir, le propriétaire n'est pas possible.
Donc on a en résumé (du point de vue des libertés):
privateur < propriétaire < libre.
Mais je suis d'accord que la plus grande menace, c'est bien les brevets logiciels.
J'ai autant de liberté avec le proprio : je peux coder aussi un émulateur de l'OS.
Et si la licence te l'interdit? Techniquement tu peux oui. Je ne vois toujours pas un cas où le privateur te donnerai plus de droits.
Comme tu peux le constater, le fait que ce soit libre (sous GPL!) ne me garantie pas qu'Apple ne pourra pas bloquer des applications.
Oui, la GPL n'est pas parfaite, tu viens de nous en donner la preuve. Mais revenons sur ce qui est important avec le logiciel libre : si les utilisateurs ont conscience qu'un tel contournement leur est préjudiciable, que vont-ils faire? Ne pas y aller, ce qui va empêcher de futurs tivoisations.
Est-ce qu'une licence peut être parfaite? Non, certainement pas. Ce n'est qu'une action après tout. L'important c'est le message, pas le vecteur. Une fois la situation changée, peut importe les actions.
pourvoir exécuter le logiciel où tu veux? Ex-aequo!
Bah ça désolé, mais je n'adhère toujours pas à ton argument de l'émulateur ou du gnome pas sous Windows. C'est une limitation "technique" là, pas une limitation de liberté. Il ne faut pas voir ce qui est fait actuellement, mais ce qui peut être fait. Un peu comme les libertés ce n'est pas tout ce que qui est déjà fait à l'heure actuelle (marcher dans la rue, voter, etc), mais tout ce que tu peux potentiellement faire si tu as envie.
tu veuilles opposer les gens plutôt que de les faire vivre ensemble
Tu te méprends sur mon objectif : il n'est pas d'abattre les logiciels privateurs, mais de faire prendre conscience aux utilisateurs que leurs libertés sont importantes. Ceci va avoir comme effet collatéral de flinger les logiciels privateurs oui. (même si en poussant le raisonnement un peu plus loin, ceci va seulement les transformer en libre, et l(utilisateur ne sera même pas lésé).
Ensuite comment on fait passer ce message : pour leur faire prendre conscience de cette importance, on leur montre un peu les effets de cette perte. Comment? Et bien avec l'exemple des logiciels privateurs justement. C'est un peu le serpent qui se mort la queue, je le reconnais, mais il faut bien réussir à faire passer le message, et s'il n'est pas illustré, il va être dur de le faire passer.
Si après cela les personnes en ont pleinement conscience, et utilise tout de même des logiciels privateurs, on n'a pas à s'y opposer. Même RMS ne viendra pas arracher un clavier des mains d'un utilisateur de logiciel privateur. On (logiciel libre) ne les aidera pas à leur priver leur liberté (intérêt de la GPL et son côté héréditaire), mais on ne va pas faire voter une loi pour interdire ce genre de logiciel. C'est contraire aux libertés mêmes que défendent les partisans du logiciel libre.
La guerre ici c'est une guerre des idées. Je n'empêcherai jamais quelqu'un d'utiliser un logiciel privateur si c'est son choix. Par contre, alerter sur les problèmes posés sur les libertés, ça c'est un devoir dont je ne vais pas me soustraire pour l'excuse que c'est difficile techniquement. Ca doit être mon côté démocratique...
Comme dit plus bas, il y a un problème avec liberté ici. Car tu as la liberté de le faire avec un système, et pas l'autre. Mais malheureusement, l'un est complexe à mettre en œuvre, l'autre non (faut pas rêver, sinon tout serait libre depuis un moment).
Ce n'est pas car personne ne l'a codé pour toi que tu ne peux pas le faire. De l'autre côté, même si techniquement tu peux, dans de nombreux cas juridiquement non.
Tu illustres bien l'open source et mon propos finalement. Avec une vision purement technique et à cours termes, tu n'est pas efficace pour la sauvegarde des libertés de la majorité des utilisateurs (certains souhaitent la soumission, mais j'ose penser qu'ils sont minoritaires) avec un tel discours.
La guerre (car c'est bien ceci que tu réfutes) consiste à sauvegarder les libertés des utilisateurs (qu'ils le veulent tous ou pas après tout). Entre un système qui t'offre le maximum pour obtenir ces libertés, et un autre, certes plus facile et accommodant, qui s'arrange pour limiter ton usage, j'ai du mal à comprendre comment on peux justifier le choix du second en terme de libertés. Facilité oui, cent fois oui évidement. Libertés? Certainement pas. Ton exemple de Gnome est une illustration de la difficulté (tu dois le coder toi même ou monter une équipe pour, dommage), pas un manque de liberté.
Que feras-tu le jour où sur ton OS il n'y aura aucun flash car refusé par l'éditeur de l'OS (tout lien avec un éditeur connu n'est pas forcément fortuit)? Techniquement tu vas pouvoir bidouiller ça bien sûr, mais bon, chercher des cracks et cie, c'est marrant quant on a moins de 10ans, après ça fatigue un peu.
Mais imagine un monde où les personnes sont sensibilisées à cette problématique. As-ton avis, que vont faire les éditeurs? Bien évidement, la minorité soumisse et/ou privilégiée à ce moment là ne sera pas joyeuse, comme l'était la monarchie lorsque l'on a donné des libertés pour tout le monde.
Tu peux (vas?) répondre que ce n'est pas un minorité mais bien la majorité, et personne ne pourra trancher. Mais au moins laisses nous un petit espoir de penser qu'il est humain de souhaiter avoir un contrôle total sur nos données et sur les transformations qui y sont effectuées.
On a eu la réponse de l'auteur sur la mailing list [1]. On peut y voir que Nagios se dirige vers un modèle 50/50 : une solution complète partiellement propriétaire (Nagios XI) qui fera entrer de l'argent pour développer la partie qui reste open source, un peu comme le fait Zenoss.
C'est un virage important dans la vie du projet, espérons que l'auteur le négocie correctement, afin de ne pas plonger tout le monde dans le ravin.
Merci à tous ceux qui ont soutenu la communauté par leur vote. Devant l'engouement sur http://ideas.nagios.org (l'idée est arrivée en première place en moins de deux jours), l'auteur n'a pas eu le choix et a répondu.
[^] # Re: Porte nawak
Posté par Jean Gabes (site web personnel) . En réponse au journal Différence de licence entre une réimplémentation complète et le projet source. Évalué à 5.
Par contre s'il souhaite juste prendre le projet sans moi, bah il peut s'il passe en GPLv2 (mais même en AGPL non?) en effet. reste à voir ce qu'il en fait ensuite en fait. S'il traite le code comme il est en train de le faire du projet open source, là je serai assez contre.
Bref, si je peux garder la AGPL pour que les utilisateurs aient un maximum de droit, je préfère bien sûr.
[^] # Re: Rapport avec les épisodes précédent ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 3.
C'est un modèle Open Core. C'est légal, mais pas très moral sachant que la communauté a été la première force de Nagios.
De plus jusqu'à maintenant Shinken avait pour vocation de réintégrer Nagios, même si son auteur l'aurait utilisé pour sa solution privatrice. Mais au moins la communauté pouvait encore le faire évoluer. En effet, les propositions d'évolutions sur Nagios ne sont pas écoutées. Ceci pose un léger soucis.
Faire un lien avec Icinga pourquoi pas, je discute beaucoup avec eux ces temps-ci en effet. Reste à voir comment se ferra un tel rapprochement. L'aspect <techniquement compatible> c'est facile, en majorité déjà fait même si Shinken propose des notions de haut niveau pas encore fournies par Icinga web (leur module web, principale force d'Icinga).
Par contre je ne chercherai pas à me couper d'autres partenaires comme Centreon par exemple. car j'adore Centreon que j'utilise tout de même tous les jours :)
J'ai pleinement conscience de la division des forces, c'est bien pour ça que je mettais ma fierté de côté et que je demandais une inclusion dans Nagios canal historique. Mais vu que ce n'est pas possible, je suis bien obligé de proposer un nouveau choix à la communauté. J'espère seulement proposé une migration si facile que ceci ne posera pas de problème à tous les administrateurs.
La version 0.2 de Shinken va justement être orientée vers l'industrialisation et la facilité de mise en place de l'outil. D'ailleurs ceux qui vont voir les sources doivent mieux s'y retrouver depuis le code de la semaine dernière.
Shinken devait être la solution pour Nagios afin de lutter efficacement contre Zenoss et Zabbix. J'espère qu'il le sera, et que ce ne sera qu'un simple nom de paquet à changer lors de la mise en place de notre cher outil de supervision.
[^] # Re: Rapport avec les épisodes précédent ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 2.
[^] # Re: Rapport avec les épisodes précédent ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 10.
Si on oublie le message précédent qui lance encore un FUD sur la marque Nagios à propos du plus grand regroupement de la communauté allemande qui a eu lieu il y a quelques temps, on peut en tirer comme conclusion que, seedcamp étant là pour trouver les nouvelles idées pour le projet Nagios, Shinken n'a même pas le droit de présence (dommage, la communauté aurait peu être eu un avis différent qui sait) dans l'environnement Nagios.
Pas de chance, il est tout de même là.
Le projet Shinken ne va donc plus chercher à intégrer le projet Nagios, vu que ce dernier n'en veut pas. Je vais faire en sorte de garder une compatibilité maximale pour ceux qui souhaite migrer, mais on peut désormais considérer Shinken comme un Fork de Nagios à part entière.
Et vive Darwin surtout :)
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 2.
Si quelqu'un se lance dans une migration vers 2.5 pourquoi pas, mais bon, dès que debian sera passé à une Python un peu plus à jour, on pourra revenir à une version plus sympathique.
Par contre là on parle pour l'écosystème GNU/Linux. Quelqu'un sait quelles sont les versions de Python classiques (entrendre en standard) pour les autres Unix (genre les Unix dont les noms commencent par un A ou un H)?
[^] # Re: Rapport avec les épisodes précédent ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 10.
Shinken n'est pas un projet renégat. Il est arrivé comme un proof of concept non public pendant plusieurs mois. Le but était à l'époque de corriger les bugs que j'avais vu dans Nagios lorsque j'ai rédigé un livre dessus. Il y avait des problèmes de conceptions lorsqu'on arrivait à vouloir monter des environnements distribués grosso-modo.
Déjà auteur de plusieurs patchs pour Nagios (même après le début de Shinken d'ailleurs), j'avais présenté ces idées en offlist, mais il me fallait des preuves du bien fondé de mes idées (Pool de process pour les performances, division des processus pour la partie distribution).
Toujours en off, j'ai développé le proof of concept et j'ai présenté les idées pour intégrations en C dans Nagios. Ce développement était donc purement technique. N'ayant aucune réponse j'ai continué le développement. Je suis arrivé à un point où il était plus facile de mettre dans le proof of concept ce qui manquait de Nagios, plutôt que de continuer à vouloir extraire les idées pour les porter en C.
Là j'ai encore proposé une idée, mais plus originale, toujours en off : inclure le code du proof of concept dans une branche de développement. Toujours sans réponses (c'est une habitude sur le projet Nagios...), je relance ma proposition sur la mailing list (décembre, soit plus de 6 mois après le début du code finalement).
Là les réactions ont étés vives, mais au moins il y a eu réaction! sauf de l'auteur par contre.
C'est après cette histoire qu'est arrivée celle entre nagios-fr.org et l'auteur de Nagios. Histoire qui ne portait d'ailleurs pas du tout sur Shinken, mais sur Icinga, autre Fork de Nagios, soutenu par une société allemande.
Je ne compte plus les mails que j'ai envoyé en off à l'auteur de Nagios avant et après la proposition sur la mailing list pour savoir ce qu'il en pensait, mais je dois tomber dans son filtre spam vu que je n'ai jamais eu une seule réponse.
Là encore j'essaie d'intégrer le projet Nagios officiel en participant au concours seedcamp alors que le projet Shinken est déjà bien parti et pourrait s'en passer. Et devinez quoi? Et bien oui, le concours est soumis à modération, et pour l'instant ma proposition n'est pas encore validée pour ce concours alors que d'autres le sont.
Il ne faut pas oublier que Shinken propose à l'heure actuelle des fonctionnalités qui ne devraient être présentes que dans quelques mois dans la version privatrice de Nagios. Ceci explique peut être cela après tout. Ça devient un peu politique, mais ce n'est pas pour me ravir, bien au contraire car je ne suis pas si doué que ça à ce petit jeu.
[^] # Re: une autre tentative est en cours
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 4.
self.process = subprocess.Popen(shlex.split(self.command), stdout=subprocess.PIPE, stderr=subprocess.PIPE, close_fds=True)
Je trouve le module subprocess bien plus pratique à utiliser que les vieux popen (qui sont de toute manière toujours présent) :)
Le journal en question n'était-il pas un pauvre troll qui a peur devant la montée en puissance de Python au cours de ces dernières années? Mais bon un troll reste un troll, il ne cherche pas à argumenter après tout.
[^] # Re: une autre tentative est en cours
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 1.
Ce type de module devrait arriver dans les autres daemons également. On peut imaginer par exemple un module pour l'Arbiter, qui est chargé de lire la configuration, module qui lirait la configuration en base plutôt qu'en fichier plat par exemple.
Un autre exemple de module serait pour le daemon poller qui est chargé de lancer les sondes. Un module pourrait être un python embarqué comme il existe du Perl embarqué pour Nagios, ou bien un module natif NRPE qui aurait de meilleures performances que de faire un popen par exemple.
Mais pour ça, il faut que je définisse comment les modules sont intégrés à ces daemons. Je prends toute aide/expérience sur ce point, comme sur tous les autres d'ailleurs.
[^] # Re: une autre tentative est en cours
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 2.
En fait le but de Shinken au début était exactement celui-là : faire un test rapide en Python, puis porter en C.
Mais en prenant un peu de recul face à la facilité de porter Nagios en Python je me suis demandé quel serait le meilleur langage pour Nagios justement. C'est un ordonnanceur (donc gérer des dates et temps) qui lance des sondes (popen sur un script ou exécutable) et qui réagit au résultat (autre popen).
Est-ce une problématique bas niveau? Je ne pense pas. Gérer le temps n'est pas un problème de calcul très violent, surtout en utilisant un peu de cache sur les calculs lourd (5 lignes...). Le popen? Et bien le module pour en Python est très efficace et pratique à utiliser.
Je ne dit pas que c'était une erreur de coder Nagios en C il y a 10ans, car c'était le meilleur compromis pour avoir une grosse communauté. Mais maintenant? Le Python s'est fortement démocratisé (il n'y a qu'à voir les stats du langage sur ohloh) et offre une maintenabilité bien supérieure au C, sans pourtant sacrifier les performances.
La migration est problématique, j'en ait conscience, et ce problème ne sera peu être jamais résolu que par une bête guerre de projet. Au pire j'échoue, mais le coup de pied au c%l du projet Nagios sera déjà ça de pris, car au moins désormais il avance un petit peu avec seedcamp par exemple.
Si maintenant quelqu'un pense le contraire et porte mes idées en C pour le cœur, je ne vais pas lui jeter les pierres, bien au contraire. Mais je ne ferai pas ce travail moi même tout simplement. Je sais qu'une partie de ce que j'ai proposé est en cours de réalisation depuis quelques temps (le pool de process). Mais ce n'est qu'une partie de ce que Shinken apporte. Et au vues du temps que ceci prends, je pense avoir raison de rester sur Python.
L'avenir nous dira qui a raison. Au pire, en cas d'échec de ma part, j'aurais fait bouger Nagios et je me serait bien marré en codant en Python.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 2.
[^] # Re: une autre tentative est en cours
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 4.
[^] # Re: Licence
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 3.
Ensuite ce n'est pas rédhibitoire car ceci ne concerne que le coeur de l'application, pas les sondes de supervision. Hors dans la quasi totalité des cas, c'est elles qui font la vraie plus value du prestataire avec l'organisation qui va autour.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 1.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 1.
[^] # Re: Ca mériterai une dépêche non?
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 6.
Le choix du Python est en fait une heureuse rencontre : je connaissais ce langage que j'apprécie beaucoup, et au début Shinken était un proof of concept pour Nagios, donc il me fallait un langage où on puisse coder vite (et bien), quitte à reporter le code en C plus tard dans Nagios.
Il s'est révélé ensuite qu'il était plus simple (et efficace) de terminer le proof of concept avec ce qui lui manquait de Nagios que le contraire.
Pour les performances en fait l'architecture permet d'avoir une distribution de la charge très facile, mais c'est surtout l'utilisation du module multiprocessing de Python >= 2.6 qui permet de gagner en performances tout simplement. Nagios passe une grande partie de son temps à forker/écrire des fichiers plats. Deux problèmes réglés avec ce module. D'où de meilleures performances tout simplement, pas de secret ici.
Par contre je n'ai pas compris les numéros entre crochets. Ce n'est pas la méthode habituelle pour les liens?
# Nom de code de la version
Posté par Jean Gabes (site web personnel) . En réponse au journal Shinken, la refonte de Nagios en Python, sort en version 0.1. Évalué à 8.
[^] # Re: Ce n'est pas une guerre!
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 0.
[^] # Re: Ce n'est pas une guerre!
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 1.
Ah! Tu viens de résumer en une phrase tout l'article. Merci :)
[^] # Re: Ce n'est pas une guerre!
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 0.
Mais justement c'est ce point que tente de traiter l'article. Si tu ne te concentre que sur "ce qui marche et point barre" comme le fait l'open source, tu n'y arriveras que très difficilement (et pour l'instant clairement pas pour les end users). Car une telle méthode est juste inefficace.
C'est pour ça qu'il faut faire prendre conscience aux personnes de l'importance de leurs libertés. Être libre sera toujours plus coûteux en terme d'effort que le contraire.
Si tu arrives à convaincre, les personnes iront vers les solutions libres, qui de fait s'amélioreront. Si tu les attires avec une simple supériorité technique, ce gain ne sera pas durable, tu pourras oublier le cercle vertueux.
Peut être que l'on s'y prends mal pour expliquer le libre, et ça semble être le cas on dirait bien. Mais ça ne le rends pas moins important pour autant.
Les libertés c'est flou, il est plus percutant (donc efficace?) d'illustrer les effets de cette perte de liberté.
ensuite si tout ceci débouche sur aucune solution utilisable pour les utilisateurs, oui, il va y avoir un problème, mais c'est que le cercle vertueux aura eu un raté quelque part, qu'il faut identifier, et régler.
[^] # Re: Intéressant. Mais...
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 2.
Mais alors on peut parler de privateur : un logiciel propriétaire (code fermé) mais qui joue l'ouverture ne sera pas aussi privateur qu'un code d'Apple par exemple.
Reste un point cependant : ok les données sont ouvertes (c'est un point clé), mais quid de savoir quelles transformations sont effectuées dessus par le logiciel? C'est moins critique je le reconnais, et tu peux toujours t'en sortir vu que tu as l'accès complet à tes données, mais si tu veux avoir cette liberté de savoir, le propriétaire n'est pas possible.
Donc on a en résumé (du point de vue des libertés):
privateur < propriétaire < libre.
Mais je suis d'accord que la plus grande menace, c'est bien les brevets logiciels.
[^] # Re: Ce n'est pas une guerre!
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 2.
Et si la licence te l'interdit? Techniquement tu peux oui. Je ne vois toujours pas un cas où le privateur te donnerai plus de droits.
Comme tu peux le constater, le fait que ce soit libre (sous GPL!) ne me garantie pas qu'Apple ne pourra pas bloquer des applications.
Oui, la GPL n'est pas parfaite, tu viens de nous en donner la preuve. Mais revenons sur ce qui est important avec le logiciel libre : si les utilisateurs ont conscience qu'un tel contournement leur est préjudiciable, que vont-ils faire? Ne pas y aller, ce qui va empêcher de futurs tivoisations.
Est-ce qu'une licence peut être parfaite? Non, certainement pas. Ce n'est qu'une action après tout. L'important c'est le message, pas le vecteur. Une fois la situation changée, peut importe les actions.
pourvoir exécuter le logiciel où tu veux? Ex-aequo!
Bah ça désolé, mais je n'adhère toujours pas à ton argument de l'émulateur ou du gnome pas sous Windows. C'est une limitation "technique" là, pas une limitation de liberté. Il ne faut pas voir ce qui est fait actuellement, mais ce qui peut être fait. Un peu comme les libertés ce n'est pas tout ce que qui est déjà fait à l'heure actuelle (marcher dans la rue, voter, etc), mais tout ce que tu peux potentiellement faire si tu as envie.
tu veuilles opposer les gens plutôt que de les faire vivre ensemble
Tu te méprends sur mon objectif : il n'est pas d'abattre les logiciels privateurs, mais de faire prendre conscience aux utilisateurs que leurs libertés sont importantes. Ceci va avoir comme effet collatéral de flinger les logiciels privateurs oui. (même si en poussant le raisonnement un peu plus loin, ceci va seulement les transformer en libre, et l(utilisateur ne sera même pas lésé).
Ensuite comment on fait passer ce message : pour leur faire prendre conscience de cette importance, on leur montre un peu les effets de cette perte. Comment? Et bien avec l'exemple des logiciels privateurs justement. C'est un peu le serpent qui se mort la queue, je le reconnais, mais il faut bien réussir à faire passer le message, et s'il n'est pas illustré, il va être dur de le faire passer.
Si après cela les personnes en ont pleinement conscience, et utilise tout de même des logiciels privateurs, on n'a pas à s'y opposer. Même RMS ne viendra pas arracher un clavier des mains d'un utilisateur de logiciel privateur. On (logiciel libre) ne les aidera pas à leur priver leur liberté (intérêt de la GPL et son côté héréditaire), mais on ne va pas faire voter une loi pour interdire ce genre de logiciel. C'est contraire aux libertés mêmes que défendent les partisans du logiciel libre.
La guerre ici c'est une guerre des idées. Je n'empêcherai jamais quelqu'un d'utiliser un logiciel privateur si c'est son choix. Par contre, alerter sur les problèmes posés sur les libertés, ça c'est un devoir dont je ne vais pas me soustraire pour l'excuse que c'est difficile techniquement. Ca doit être mon côté démocratique...
[^] # Re: Ce n'est pas une guerre!
Posté par Jean Gabes (site web personnel) . En réponse au journal Qui est le plus "efficace" : l'open source ou le logiciel libre?. Évalué à 5.
Ce n'est pas car personne ne l'a codé pour toi que tu ne peux pas le faire. De l'autre côté, même si techniquement tu peux, dans de nombreux cas juridiquement non.
Tu illustres bien l'open source et mon propos finalement. Avec une vision purement technique et à cours termes, tu n'est pas efficace pour la sauvegarde des libertés de la majorité des utilisateurs (certains souhaitent la soumission, mais j'ose penser qu'ils sont minoritaires) avec un tel discours.
La guerre (car c'est bien ceci que tu réfutes) consiste à sauvegarder les libertés des utilisateurs (qu'ils le veulent tous ou pas après tout). Entre un système qui t'offre le maximum pour obtenir ces libertés, et un autre, certes plus facile et accommodant, qui s'arrange pour limiter ton usage, j'ai du mal à comprendre comment on peux justifier le choix du second en terme de libertés. Facilité oui, cent fois oui évidement. Libertés? Certainement pas. Ton exemple de Gnome est une illustration de la difficulté (tu dois le coder toi même ou monter une équipe pour, dommage), pas un manque de liberté.
Que feras-tu le jour où sur ton OS il n'y aura aucun flash car refusé par l'éditeur de l'OS (tout lien avec un éditeur connu n'est pas forcément fortuit)? Techniquement tu vas pouvoir bidouiller ça bien sûr, mais bon, chercher des cracks et cie, c'est marrant quant on a moins de 10ans, après ça fatigue un peu.
Mais imagine un monde où les personnes sont sensibilisées à cette problématique. As-ton avis, que vont faire les éditeurs? Bien évidement, la minorité soumisse et/ou privilégiée à ce moment là ne sera pas joyeuse, comme l'était la monarchie lorsque l'on a donné des libertés pour tout le monde.
Tu peux (vas?) répondre que ce n'est pas un minorité mais bien la majorité, et personne ne pourra trancher. Mais au moins laisses nous un petit espoir de penser qu'il est humain de souhaiter avoir un contrôle total sur nos données et sur les transformations qui y sont effectuées.
# On a la réponse
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Nagios : l'auteur tente de museler sa communauté pour cause d'avoir été trop libre. Évalué à 3.
C'est un virage important dans la vie du projet, espérons que l'auteur le négocie correctement, afin de ne pas plonger tout le monde dans le ravin.
[1] : https://sourceforge.net/mailarchive/forum.php?thread_name=4B(...)
[^] # Re: Vote de soutient pour la communauté nagios
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Nagios : l'auteur tente de museler sa communauté pour cause d'avoir été trop libre. Évalué à 5.
...
Bon en fait il a répondu complètement a côté de la plaque en se moquant de la demande de la communauté (https://sourceforge.net/mailarchive/message.php?msg_name=4B8(...) ), puis a fermé le vote et enfin a re-tenté de répondre par une attaque personnelle (http://www.monitoring-fr.org/2010/02/soutenez-notre-appel-cr(...) ).
Mais bon au moins maintenant on sait qu'il est en vie, c'est déjà ça.
[^] # Re: Alerte Nagios
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Nagios : l'auteur tente de museler sa communauté pour cause d'avoir été trop libre. Évalué à 1.