Jean Gabes a écrit 499 commentaires

  • [^] # Re: Tu m'excuseras de rire...

    Posté par  (site web personnel) . En réponse à la dépêche Shinken version 2.0. Évalué à 4.

    C'est tout à fait juste, je sais donc quoi rajouter pour la première release bug fix merci :)

    Perso ce qui m’embête plus n'est pas le paramétrage à 0 par défaut qui restera ainsi, mais plus qu'il ne soit pas modifiable. Heureusement ça va se gérer plutôt bien surtout qu'on a déjà le paramètre géré côté conf, il suffit de le relier au bon endroit :)

    Vu que tu as l'air efficace dans le domaine je t'invite à aller voir du côté de l'UI web de shinken vérifier qu'il n'y a pas de soucis (https://github.com/shinken-monitoring/mod-webui/blob/master/module/module.py). Bon on a pas de https qui est laissé à un frontal si besoin est, mais si tu peux prendre un peu de temps pour regarder ça nous aiderai bien :)

  • [^] # Re: explosion mémoire dû aux commentaires

    Posté par  (site web personnel) . En réponse à la dépêche Shinken version 2.0. Évalué à 4.

    Pas con, j'en rajoute un pour voir :)

  • [^] # Re: explosion mémoire dû aux commentaires

    Posté par  (site web personnel) . En réponse à la dépêche Shinken version 2.0. Évalué à 5.

    Je n'ai pas encore réussi à le reproduire, donc j'imagine que oui. En même temps de mémoire on ne me l'a remonté que sur une seule installation. Je suis beaucoup de grosses installations et aucune ne m'a remontée le problème encore :)

  • [^] # Re: packs et modules

    Posté par  (site web personnel) . En réponse à la dépêche Shinken version 2.0. Évalué à 6.

    Je confirme que tu as mal compris :)

    Il stocke les tar.gz des packs et modules directement :)

  • # oh bah heu... merci :)

    Posté par  (site web personnel) . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 10.

    Ah ça fait plaisir de voir son nom cité tiens :p

    Bon petite news en passant pour pas faire un commentaire un peu vide: nouvelle version de Shinken la semaine prochaine a priori :)

    Sinon pour revenir au sujet, je pense que c'est une très bonne chose de mettre en avant les développeurs, et montrer ce qu'ils peuvent créer comme valeur. Le jour où on aura en France un bon dev payé bien plus cher que son petit chef on aura fait un grand pas en avant, et on arrêtera peu être l’hémorragie vers les US (faut dire que quand ils arrivent et proposent salaire_fr*5 ça calme) …

  • [^] # Re: C'est open non?

    Posté par  (site web personnel) . En réponse au journal De bonnes poires. Évalué à 3.

    Je suis plutôt d'accord avec ça. Il se doit d'être clean sur sa sortie et de ne mettre personne dans la me%#e en supprimant par exemple sans les céder les sources du site communautaire par exemple. Mais de là à se devoir de rester alors qu'il n'en a plus envie non, là aucunement.

    Il ne faut pas oublier que les autres ont aidées pour leur propre intérêt comme le dirait si bien notre Linus nationWinternational. Ils y ont pris du plaisir et encore heureux, mais de là à ce que leur aide ait en contre-partie sa servitude je ne suis pas d'accord (car c'est bien de ça dont on parle s'il doit rester dans un projet dont il n'a pas envie, c'est comme si on demandait à un codeur de faire du PLSQL d'oracle, personne n'en a envie).

    Je veux dire que même d'un point de vue éthique ce qui compte c'est la manière où il gère sa sortie, mais le fait de pouvoir sortir ne devrait pas être optionnel. Certains projets on très très mal gérés cela dans le passé genre en le faisant mais sans vraiment le dire. Là c'est assez clean je trouve même si le délai est un peu short. Si une personne motivée a les moyens avec ce qu'il laisse de reprendre le flambeau sans repartir de 0 (il y a toujours le nom qui est source soucis, car sa propriété) il n'y a pas de soucis. Si par contre il fait exprès de cramer ce que tout le monde a participé à bâtir (genre il drop les différents sites, forum and co avant de partir) là non ce n'est pas clean par contre :)

  • # C'est open non?

    Posté par  (site web personnel) . En réponse au journal De bonnes poires. Évalué à 10.

    Donc fork. Il pars de son côté, c'est son droit je pense. La limite de 10jours est elle carrément limite quant à elle.

    Si la communauté est si bien organisée que tu le dis, aucun soucis, un nouveau lead prends le pas, on change de nom et c'est reparti. C'est impactant j'en conviens, mais bon c'est aussi sa liberté de le faire non? Il me semble que l'on a pas le droit de lui enlever.

  • # Quelle guerre?

    Posté par  (site web personnel) . En réponse au journal La guerre des forges. Évalué à 9.

    Il me semble que github aspire une grande majorité des projets. Si quelqu'un a des chiffres ça serait intéressant d'ailleurs.

  • # Quid côté stats entre projets "similaires"

    Posté par  (site web personnel) . En réponse au journal La GPL est un échec (FreeBSD 10 est sorti). Évalué à 4.

    Plus sérieusement que l'armée de troll qui ne va pas tarder à se lancer à l’assaut, est-ce que certains ont des stats sur justement le nombres de projets lancés par rapports aux types de licences, et à projet "équivalents" (pas de gros car la licence joue moins) quel type a le plus de contributions.

    Par exemple avec toute l’effervescence nodejs et javascript, je pense que les types BSD poussent forts. Est-ce que d'autres domaines restent fortement typés GPL?

    J'ai ma petite idée en tant que mainteneur de projet GPL sur les résultats, mais j'aimerai bien des statistiques réelle que mon ressenti :)

  • [^] # Re: Propriété

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 3.

    Ne t'inquiète pas, on va s'arranger héhéhé :)

  • [^] # Re: Propriété

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 4.

    Pénalisant pour l'image et la dilution des forces, mais ça permet également d'abaisser la barrière d'entrée de nouveaux projets (plus dur de faire face à un "gros" que X plus petits). Donc au final l'écosystème n'est pas si mal en point. De plus ils s'éloignent de plus en plus les uns des autres, donc on va avoir des situations plus claires pour choisir LE bon outil à sa situation. Ca donne plus de travail aux consultants ;)

  • [^] # Re: Propriété

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 4.

    C'est pas faux, mais on s'amuse bien dans le milieu justement, c'est une sorte d'animation de la communauté comme une autre :p

  • [^] # Re: Propriété

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 5.

    Ce n'est pas complètement faux non plus. La raison est historique, le site a été monté par ses auteurs précédents, mais la société a réclamé la propriété de l'enregistrement DNS car il y avait nagios dans le nom, ce que les auteurs ont fait (pour ne pas se froisser avec l'auteur de nagios). Donc on était dans une situation "anormale" en effet après tout, là c'est un mal pour un bien, ça clarifie les choses et on va avoir un équivalent nagios-exchange.org/monitoring-exchange.org (oui c'est pas la première fois que cette histoire se passé :) ).

  • [^] # Re: Difficile à comprendre de la part de l'auteur de Nagios

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 4.

    Oui en effet, je l'ai déjà dis dans le passé et ça se vérifie: il est mon premier "commercial" :). Mais il bat un nouveau record en terme d'image. Ce qui est ironique c'est que c'est justement pour protéger son image qu'il fait tout ça…

  • # Difficile à comprendre de la part de l'auteur de Nagios

    Posté par  (site web personnel) . En réponse au journal Changement d'URL pour les "plugins" Nagios. Évalué à 6.

    Le plus fort c'est que commercialement il n'y a aucun intérêt à faire ça. Le pire qu'il peut être "reprocher" aux mainteneur des sondes était de dire clairement qu'elles étaient également pour les autres outils du monde nagios (centreon-engine, icinga, naemon et shinken). Enfin bon ce n'était pas non plus un crime si grave, pas de quoi flinguer le site sans aucun avertissements…

    J'ai beau chercher là j'ai du mal à comprendre ce qu'il a fait. D'habitude il y a une raison commerciale assez claire, mais là ce sont juste les sondes, et je vois mal comment les modifier pour les monétiser.

  • [^] # Re: shareware ou logiciel libre payant ?

    Posté par  (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 6.

    Oh mais je ne disais pas du tout que c'était débile d'aller vers là, bien au contraire :)

    Le truc c'est qu'à chaque fois que l'on parle d'économie & open source/libre on arrive au modèle des services genre intégration. Mais voila, ce modèle fait vivre les intégrateurs, pas les dev/éditeurs justement. Il ne faut donc pas s'étonner que de plus en plus d'outils s'orientent vers de l'open core ou cherchent à rendre l'utilisation sur certains OS payantes (en gros pour 99% des personnes devoir recompiler sous Windows est de l'ordre de l'impossible, donc on a bien créé une barrière virtuelle ici), ou la pub (on utilise la popularité de l'outil, mais ça demande donc une audience monstrueuse, qui par définition ne sera atteinte que par quelques outils seulement).

    Pour le Big Daddy c'est bien ce que je disais. Le modèle est valide car justement de gros acteurs ont tout intérêt à ce que l'outil se développe fortement pour booster leur propre business. Donc là aucun soucis à ce que ça reste open source.

    Mais dans le monde "normal", avec un outil "normal" on a pas la visibilité de Firefox, ni de gros acteurs qui veulent payer les dev (car on fait un outil qui concurrence les offres des gros par exemple). Or les intégrateurs sont ravis de pouvoir faire du chiffre avec la version open source, mais ne participent que très très peu au dev (quand ils participent tout cours…). Pouvoir payer un salaire avec du dev à la demande ça se fait, mais si on veux pouvoir embaucher pour faire plus de dev par exemple là ce n'est plus tenable comme modèle.

    Le modèle open source n'est donc pas viable comme tel dans le système économique actuel. Or en effet il faut être réaliste et l'adapter (genre open core). Ce qui m'étonne c'est que beaucoup semblent encore penser que ce modèle est viable pour tous les outils. Or non, il ne l'est pas. On a quelques exceptions bien sûr, mais soyons sérieux dans la majorité des cas ça ne marche pas.

    Il ne faut donc pas s'étonner que de plus en plus d'outil (surtout d'infrastructure) s'orientent vers de l'open core. On avait déjà Nagios et Centreon, on a aussi Puppet, Cfengine, Nginx et prochainement Shinken. C'est dommage mais bon réalité fait loi :)

  • [^] # Re: shareware ou logiciel libre payant ?

    Posté par  (site web personnel) . En réponse au journal Financement des applications sur le 'bureau'. Évalué à 2.

    Je me demande si ce n'est pas la méthode la plus efficace pour que l'auteur ne développe plus du tout sur la version libre :)

    Le fait d'en arriver à un tel modèle économique devrait se faire poser des questions à pas mal de monde de la communauté, car c'est de plus en plus la norme. On en arrive à quand même contourner l'esprit (accès sans limite) avec une astuce (source!=binaire), il y a un vrai soucis d'adéquation entre le principe du libre et le système économique actuel. On pourra avoir quelques victoires de temps en temps sur des niches qui s'y prêtes bien (Firefox et OpenStack avec leur modèle économique "big daddy" ou RedHat avec son modèle "masse critique permettant la certification par les grosses applications"), mais on est pas prêt d'arriver à le généraliser en l'état.

  • [^] # Re: Rumeur ?

    Posté par  (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 2.

    Pourquoi ne pas envoyer directement un mail à l'auteur de naemon? Il est très ouvert et réponds volontiers aux mails :)

  • [^] # Re: Bon ben il est l'heure d'aller voir du côté de Shinken si l'herbe est plus verte.

    Posté par  (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 2.

    Ah ce n'est pas du click and run c'est certain :p

    Les deux sont pensés pour être des frameworks de supervision et non pas des "solutions". Ils sont donc à mettre dans les mains de quelqu'un qui souhaite maîtriser réellement sa supervision, en la concevant de bout en bout (même si dans Shinken on a à disposition des recettes pour les cas classiques, l'admin est encouragé à les adapter à son besoin).

    Facilité ou flexibilité en gros :)

  • [^] # Re: Bon ben il est l'heure d'aller voir du côté de Shinken si l'herbe est plus verte.

    Posté par  (site web personnel) . En réponse au journal [Bookmark] Nagios fork. Évalué à 8.

    Pour info on a de petits soucis de perf sur www.shinken-monitoring.org, je suis en train de creuser ça.

    Sinon pour icinga, c'est assez vaste en fait. En gros surtout du distribué (load balancing ET haute dispo), une focus sur la recherche des problèmes sources et une notion d'importance métiers sur les alertes (savoir qu'un serveur est tombé c'est bien, savoir qu'il a impacté à 20 niveaux de dépendances en dessous une application critique c'est mieux :) ).

    Par contre icinga vient de base avec une interface de configuration (lconf de mémoire) là où il faut le mettre en place soit même pour Shinken. Ils ont aussi repris et amélioré l'interface de Nagios, là où Shinken a la sienne (en fait elle ne présente pas les mêmes choses tout simplement).

    Le mieux ça reste encore de tester les deux, et d'aller lire le hors série Linuxmag de septembre 2012 dédié à Shinken pour mieux voir ce dont il est capable :)

  • [^] # Re: Est ce que la solution...

    Posté par  (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 3.

    Malheureusement ce sont ceux qui font le plus de bruits en effet. Je ne doute pas qu'il y ai aussi une armée de bonne volontés qui travaille à faire encore mieux que les cgroups pour les BSD, mais par définition ils travaillent, donc on ne les entends pas c'est dommage.

  • [^] # Re: Est ce que la solution...

    Posté par  (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 2.

    Tout à fait. Demander à ce que tous les noyaux soient au même niveau quand on souhaite améliorer les souches supérieures reviendrait à ne pas avancer. Linux et les BSD n'avancent pas sur les mêmes sujets en effet, mais est-ce un mal? De plus personne n'a le droit de demander à un autre d’arrêter d'avancer sur un sujet car son "camp" ne suit pas le rythme. Par contre ça doit motiver à suivre, voir innover ;)

  • [^] # Re: Même situation, mais des pistes

    Posté par  (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.

    Il me semble qu'elle a une petite sœur dans le genre, un peu plus large, ça a été évoqué dans un commentaire de la (longue) histoire Linkeo.

    Puis bon, si je le fais c'est que je n'aurais pas encore compris comment ne pas me retrouver dans cette situation. Or là ça restera gravé dans ma mémoire au fer rouge, donc je suis sûr de ne pas l'oublier lors de mes prochains échanges avec des SSII/LL (j'arrive de moins en moins à faire de différence entre elles à vrai dire quand on parle des plus grosses).

  • [^] # Re: Même situation, mais des pistes

    Posté par  (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.

    Par ces clients là, car il pourraient en appeler à une sorte de diffamation : ils pourraient rétorqués que par rapport à certains contrats cadres qu'ils ont avec d'autres fournisseurs ça va leur porter préjudice.

    Puis bon à la limite c'est le jeu, pourquoi pas. Ensuite à moi de faire comprendre que la règle sera que désormais pour avoir de l'aide, faudra faire un effort. Ca ne sert à rien de se plaindre d'une situation, autant en tirer des leçons pour ne pas recommencer les mêmes erreurs plus tard :)

  • [^] # Re: Même situation, mais des pistes

    Posté par  (site web personnel) . En réponse au journal L'open source va me tuer .... Évalué à 2.

    Je ne suis pas sûr car je ne peux pas prouver qu'ils l'utilisent après tout :(