Jean Gabes a écrit 458 commentaires

Pour l'instant la doc a été rapatriée des sources sous format docbook vers le wiki (dokuwiki) sur le site officiel pour inciter tout le monde à l'améliorer (le coup d'entrée de docbook est important, un wiki est bien plus accessible).

Ceci implique que pour l'instant il n'y a plus de doc pdf fournie avec l'outil. Mais vu que le format de données de dokuwiki est connu et en fichier plat, une transformation en pdf doit être possible, je vais voir comment faire (dokuwiki->rst->sphinx peux être).

Pour le livre, on verra si un jour je m'attaque à la seconde édition de mon livre sur Nagios ;)

Bonjour,

En gros après un soutient de notre cher RMS qui pense que l'auteur de Nagios avait tord, ce dernier n'a pas donné de nouvelle. Fin du FUD, retour au code (et tant mieux) :)

Si on a un problème réseau et qu'on aimerait tout de même être alerté, un bon moyen c'est Gnokki avec un bête téléphone branché en USB sur la machine. Très simple à intégrer aux outils de supervision en plus :)

Non non, ceci prouve deux choses :
*je ne me relis pas assez
*j'ai réellement besoin d'un vrai webmaster :)

Merci en tout cas.

En effet, c'est sacrément ressemblant :p

Je suis parti d'une image sur kde-look avec le samouraï qui se bat contre un arbre en svg. Mais si au hasard ta femme est motivée pour arranger notre logo, je ne suis pas contre, car elle semble être sacrément douée, j'adore ce qu'elle a fait :)

En ce qui concerne la configuration hôte/service, pour l'instant il y a pas mal d'avancée, mais la principale sera pour la version 0.5 je pense (en fait déjà dans la 0.4 mais en expérimental). Il sera bien plus "logique" de configurer la supervision d'un serveur sans avoir à passer par les groupes et cie. Car là en effet, la configuration est vraiment puissante (héritage et cie) mais elle n'est pas simple, pas simple du tout.

Oui c'est tout à fait exact. Nous sommes 7 a avoir accès au git en écriture désormais. Tous ne sons pas actifs très régulièrement, mais ça avance :)

C'est vrai que j'ai passé la partie "projet" un peu rapidement dans ce journal, mais je en voulais pas faire un pavé non plus.

Merci, ceci sera corrigé :)

Ah bah nan, je crie suffisamment sur l'orientation de Nagios pour ne pas faire de même :)

Quoi que ça pourrait être rigolo de le faire juste pour se moquer des open core : Entreprise, même licence que la libre, mais plus chère :)

Et si je fais un effort et que je le nomme 0.3 SP1? :)

Je pense qu'elle va attendre la 0.4. Je ferai un petit récapitulatif comme celui là mais avec la 0.4 avec. Surtout qu'elle ne devrait pas tarder car j'ai déjà rempli pas mal de manques depuis la 0.3 du début de semaine :)

Avec la 0.4 on pourra faire une dépêche : bon maintenant, vous pouvez y aller avec votre prod :)

Oh mon cher journal, j'ai oublié de te parler d'un site monté suite à la discussion sur le projet : le site de propositions/votes pour les futures fonctionnalités.

Il est disponible sur <a href="http://shinken.ideascale.com"<http://shinken.ideasca(...) et tu peux y rajouter les fonctionnalités que tu veux ou bien voter pour celles qui te paraissent les plus importantes.

Ces votes vont influer directement sur la roadmap du projet pour les futures versions, donc je t'invite à voter oh mon cher journal.

Tu as dans Centreon (en fait le module ndo) des paramètres de purges qui sont un peu élevé de base, mais ils existent il me semble (ndo2db.cfg).

Mais en effet de toute manière l'utilisation d'une bdd dans ce cas là n'est pas si utile. Concernant Thruk c'est que justement il utilise le module LiveStatus qui est en fait un moyen pour le daemon Nagios d'écouter sur un port des requêtes (format spécial mais très simple d'utilisation) et de répondre. Point de bdd ici (en fait si, le daemon se transforme en bdd sans rétention finalement).

De plus en plus d'outils gravitant autour de Nagios font le choix de livestatus (plus de base MySQL à installer/gérer) lorsqu'il ne s'agit que de voir les infos en temps réels comme par exemple NagVis qui est un moyen d'avoir de jolies cartes agrégées et qui n'a clairement pas besoin de la rétention d'information sur le long terme.

Centreon n'a pas encore franchi le pas, et s'oriente plutôt pour l'instant vers un nouveau schéma de base bien plus léger et performant que le classique de Nagios (NDO) avec leur nouveau module d'export (CentreonBroker).

Bref ça bouge pas mal ces temps-ci dans le domaine, les idées fusent c'est cool :)

C'est vrai que lorsque ça touche au politique sans aucun rapport de près ou de loin avec le libre, je ne vois pas trop pourquoi ceci resterait sur Linuxfr. Il y a d'autres sites pour échanger (troller?) sur la politique, qu'ils y aillent, on ne les regrettera pas.

Et voici les deux mails de Richard:

"I am not a lawyer, but I know the answer is not so simple.

You can use the algorithms you learn from reading their code, but
translating the code into another language would surely infringe
copyright. For intermediate possibilities, the answer may not be
clear, so you would need to talk with a lawyer for advice."

Et quand je suis ais précisé le cas précis :
" Moi:
Thanks for the answer. The exact case is that I look at the code to
look at how some parameters are done (I look at the regexp), but The algorithm to find and parse them is my own.

Richard Stallman :
In that case, you are probably ok; but I am not a lawyer.
You should check with a lawyer if you want real legal advice.
APRIL could help you find a French lawyer.
"
La situation était précisément dans notre cas : lecture des regexp dans le code de Nagios, et réécriture complète de l'algorithme et des regexp dans le code de Shinken. Ceci est simple à prouver en effet, car mon code est bien plus long que celui de Nagios sur ce point (oui moi et les regexp, c'est comme moi et l'anglais hein...).

Bref, je pense que l'on peut éviter la case avocat. Si bien sûr l'auteur persiste, je ferai appel à APRIL pour des conseils.

Merci en tout cas à vous pour vos conseils, ceci m'a bien aidé dans cette histoire :)

Maintenant, retour au code.

Ah merci. J'espère que les modérateurs vont accepter mes explications en anglais, car moi et le chinois traditionnel bah...

En effet, j'espère qu'un mail de Richard sera suffisant pour calmer les ardeurs, et que l'on pourra se concentrer sur le code, et non pas les licences et autres biais de limitation d'innovations. Surtout que vois une guerre de licence entre logiciels open source, ça laisse tout de même un goût amère :(

J'ai bien compris qu'il vaut mieux pour les deux projets se différentier pour éviter les amalgames et les éventuels problèmes de copyright avec Nagios Enterprise (ils sont bien plus doués que moi dans le domaine, je ne compte absolument pas jouer avec eux sur ce terrain là).

Je suis en pleine préparation des slides pour les RMLL à ce sujet justement, et je vais bien faire attention à la manière dont je présente ce projet (genre bannir le terme fork) grâce à vos conseils, merci :)

J'en profite pour rappeler que dans l'email que j'ai renvoyé à l'auteur j'ai fait mention de trois tickets assez "faciles" sur le trac. Si certains sont curieux du fonctionnement interne du projet, c'est une bonne occasion de voir comment il est fait ;)

Merci beaucoup.

Héhé, je n'ai pas vu le fichier licence en tout cas :)

J'ai eu une réponse de Richard Stallman (je lui ais demandé si je pouvais la poster, j'attends sa réponse). En gros si je ne fais que rependre l'algorithme mais avec mon propre code (donc pas de traduction sans réfléchir) c'est bon.

Donc le clean room design ne semble pas d'actualité, même si Richard dit que c'est un sujet épineux.

Donc j'attends l'autorisation de Richard de publier son email (il a un peu plus de poids que moi dans le domaine) et je redemande à l'auteur de Nagios de montrer le code qu'il pense litigieux.

Je vais quand même lui rappeler qu'il y a un morceau de code en commun (enfin un algorithme), mais vu qu'il est de moi dans le code de Nagios...

Merci.

En fait je n'ai pas piqué de code, j'ai regardé comment son algorithme faisait pour détecté des paramètres non documentés (en gros j'ai regardé les regexp quoi). Ensuite j'ai refais le mien (qui d'ailleurs est plus long, honte sur moi...) avec de nouvelles regexp (car moi et les regexp j'ai du mal, alors j'ai fait des regexp plus simple, ce qui explique la longueur du code en fait).

Bref, à part me reprocher de ne pas avoir appliquer un clean room design, bah j'ai juste compris l'algorithme et appliqué le mien.

Devoir réécrire ce code pourquoi pas, mais si de toute manière il me reproche d'avoir lu le code de Nagios, bah je ne vais pas l'oublier en effet, donc je ne peu plus toucher à mon propre code? Plutôt ubuesque comme demande...

Sinon oui j'ai repris un algorithme directement (6 lignes de code hein..) car je l'avais fourni à Nagios, et là en effet, il ne peux rien me reprocher (d'ailleurs ile ne m'a jamais dit merci pour ce nouvel algorithme... :( ).

Je n'ai pas peur d'affronter le canal historique en effet. C'est juste que j'aurais préféré qu'on travaille tous ensemble plutôt que devoir faire appel à des avocats :(

Oui, de plus il fallait que j'écrive la doc sur cette partie (comment sont formés les éléments des timeperiods), mais je comptai expliquer avec ce que j'avais compris du code pour les utilisateurs, pas pour un autre codeur :)

Enfin, faisons déjà la documentation, ça sera ça de fait de toute manière.

Merci, c'est plus clair comme ça :)

C'est une bonne question. Là l'auteur par sur "derivated work" qui est bien plus flou qu'un simple copier/coller de code, et j'imagine bien moins limité dans le code justement.

C'est pour cette raison que dans ma réponse j'ai vraiment limité la portée de ce possible "derivated" à une portion minime.

Mais oui, quid entre maintenant et la réécriture si la FSF abonde dans son sens? Je sors la fonction dans un fichier à part et j'y applique la GPLv2 et c'est tout?

Ah il me semblait que des katanas fait par des non japonais ne pouvais être appelé Shinken justement. (référence Wikipedia et ma mémoire), mais étaient tout de même des katanas.

Bon en tout cas c'est un morceaux d'acier trempé qui permet de se raser la matin en gros :)

Merci beaucoup. J'ai corrigé la version chinoise traditionnelle, mais il reste la version allemande si quelqu'un connait cette langue.