Jean Gabes a écrit 439 commentaires

Remarque: les réponses à un commentaires en négatifs devaient peu être être mis en cachés eux aussi? Ca éviterait l'effet pavé et qu'on perde du temps sur un échange qui part sur du vent?

C'est juste. Mais j'ai la forte impression (peut être fausse) qu'on a de plus en plus le cas. Il est possible aussi que je fasse de plus en plus attention à ces posts qui ressemblent plus à des formules de rhétoriques qui pour son auteur est un moyen d'être visible et "avoir raison" sans trop avoir à réfléchir sur le fond.

Le système de notation aide, mais j'ai encore vu dernièrement des pavés énormes sur un point de détail sur un terme (je ne me souviens plus tellement ça ne m'intéressait pas).

J'encourage les modérateurs a être un peu lus ferme sur ce genre dérive ou au moins ouvrir le débat car mine de rien, et là encore c'est peu être juste une impression, on a de moins en moins de débat technique dans les commentaires. Or c'est bien pour ça qu'on vient sur le site, pas pour être sur un sous domaine de bescherelle.fr :)

Bon c'est la fin du passage vieux con qui couine, même si j'ai pas encore tout à fait l'age :)

Et vive les débats techniques et de fonds donc :)

Un ami m'a dit hier qu'il ne lisait plus les commentaires sur linuxfr à cause du temps perdu par beaucoup sur des détails d’orthographes ou de terme pas totalement adéquat en laissant de côté le fond.

Et là bravo, tu es en plein dedans. Dans le genre de perds mon temps sur un point de détail digne d'une dicté de Pivot tu places la barre bien haut.

De l'importance d'avoir deux UIs (web et "console pleine") pour plaire à un maximum? Le coût qu'un tel choix impose au projet et à sa maintenabilité? Ou alors plus simplement un choix de librairie améliorable pour une certaines partie d'une ou autre UI? Non, c'est beaucoup plus intéressant de parler forme et pinaillage de mot.

Je commence à comprendre mon ami pour le coup.

Juste une remarque sur le load average, ça n'a pas vraiment de sens à le mettre en pourcentage. Le comparer au nombres de CPUs (ici j'imagine qu'il y en a un seul?) est un résumé vraiment approximatif pas représentatif sur de vrais serveurs. Ca aurait beaucoup plus de sens de prendre la somme des CPU en %user+%sys par exemple :)

Dans le même genre d'outil il y a glances qui est très avancé également et là aussi présent en deux versions :)

Dommage que les gens qui n'ont pas de temps à perdre le fassent perdre aux autres.

C'est justement là que je ne suis pas d'accord. ils sont là pour faire gagner du temps à la majorité des leurs utilisateurs. Se prendre la tête sur une niche de ces derniers c'est impacter les autres, ni plus ni moins. Or ils ne te doivent rien, même si tu es un utilisateur (point que beaucoup d'utilisateurs du libre semblent oublier je pense…).

Ton avis n'a pas plus d'importance que celui de madame michu qui aimerait bien que ses vidéo youtube tournent plus vite sur son vieux pc. Or ça demande du temps mais ça aide 99% de leurs utilisateurs. Chercher à développer pour le dernier % des utilisateurs est une perte de temps abominable qui ne devrait pas être faite, et qui je pense pour ce genre de gros projet est heureusement non faite sinon ils n'avanceraient jamais sur leur "cœur de métier".

Tu veux que ça soit géré? Donne leur un code propre, facilement maintenable et même de l'aide pour le maintenir justement. Là tu as une chance que ça soit accepté. C'est l'unique intérêt du libre il me semble. Je suis d'accord que tu vas déjà plus loin qu la plupart des utilisateurs en ouvrant un ticket, mais ça ne change pas grand chose, ils ne te doivent toujours rien.

Tu n'es pas dans le cœur de cible du projet. Pour que ce soit le cas il faudrait que beaucoup d'acteurs s’allient pour pousser bien fort le desktop linux et ce sur tous ses aspects (le code ce n'est que 10% des efforts à produire). Mais bon là on s'écarte, et vu que ce lundi ressemble à un vendredi on va s’arrêter là sur ce sujet polémique :)

En fait, en France en tout cas, la supervision est ue uniquement d'un point de vue "technique", comme "juste" un outil pour les admins mais qui n'a pas d'influence sur les métiers de l'entreprise.

Or je ne vais pas vous apprendre que plus c'est "technique" et plus c'est mal vu en France. Or la supervision peut, et même doit, être orienté vers les applications métiers, afin de les aider à toujours être en état de marche. C'est un long travail et le fait d'avoir un nagios qui se focalise sur l'IT d'un point de vue bas niveau n'aide pas à faire comprendre que si, on peut être supervision et haut niveau (genre ce qu'on a avec les bp_rule et shinken).

Corollaire: si c'est technique et peu important on ne mets pas les moyens, donc on mets un stagiaire. cqfd.

C'est bizarre, mais j'ai rarement des questions de stagiaires des US par exemple, mais surtout en France. Or on a beaucoup de shinken aux us aussi, mais le plus souvent ce sont les admins expérimentés qui le mettent en place.

Bon au final ça fait de bon sujet de stage, et ça marche pas si mal avec un très bon stagiaire. Le soucis c'est que quand on en mets un pas très débrouillard, bah ça donne pas grand chose, normal après tout :p

Je prends :)

Ca ne doit être que sur le (ou les) schedulers car le poller ne sait même pas ce qu'est un commentaire :)

Question: est-ce que ce sont des commentaires liés à des downtimes? Si oui, des downtimes auto ou manuels?

Bon bah ça sent la chasse des comments dans le code alors :)

Lol, j'aime bien l'idée, surtout qu'on pourrait facilement le faire en demandant le changement d'un flag sur l'API http justement :p (jolie ironie non?)

c'est vrai que le message d'erreur de libcurl est vraiment cryptique en plus. Je me le note pour la prochaine version de le catcher et proposer une solution de contournent ou un simple lien vers la doc qui l'explique en fait :)

Là le moindre admin qui regarde les precos ou qui va se demander comment le stagiarie à fait sans lui demander un certificat va savoir directement qu'il y a un soucis.

Donc on a plus un soucis d'organisation, et si on mets en place le 1 par défaut, on va juste avoir le ssl de désactivé systématiquement ce qui n'est gère mieux. On n'aura pas le faux sentiment de sécurité c'est vrai, on en aura carrément pas :)

Bon après ça permets justement de lever un signal d'alarme.

Est-ce que ça va poser un soucis dans certains endroits? oui peu être, mais ça leur montrera aussi que la mise en place d'un tel outil doit être fait par une personne qualifiée, et pas par un stagiaire.

Dans les SI où les admins prennent ça au sérieux et savent lire le commentaire qui est une ligne en dessous du paramètre d'activation du HTTPS ça ne posera aucun soucis, et sincèrement c'est bien eux mes utilisateurs principaux.

Je comprends ton point de vue, et oui c'est tout à fait justifiable de forcer un paramètre sécurisé dès le début, mais vu qu'il va n'impacter que ceux qui n'en ont pas grand chose à faire et va pourri la vie des mainteneurs sans impacter ceux que ça intéresse, le jeu n'en vaut pas la chandelle.

Ensuite ça n’empêche pas que je vais rajouter une page dans la doc sur l'activation du SSL avec justement un petit focus là dessus et un petit warning dans les logs par exemple. Si le stagiaire pense que c'est vraiment sécurisé alors que la ligne juste en dessous a un gros warning sur la sécurité, qu'il se prends un log de warning et que la doc a un point spécial là dessus, c'est qu'il est cliniquement con :)

Pas trivial comme problématique je dois bien l'avouer, et je suis un peu biaiser vu que je suis l'un de ceux qui devraient gérer l'afflux de demandes sur les forums. On verra bien dans le futur si on change le paramètre ou pas. Mais bon on part sur cette version sur une responsabilisation des utilisateurs justement, avec l'arrêt du script d'install automatiques et le non paramétrage par défaut de pleins de trucs de manière un peu magique. Je préfère suivre cette logique et voir ce que ça donne :)

Ps: je n'ai rien contre les stagiaires, on a tous commencé comme ça dans la supervision, mais il faut bien reconnaître que la proportions de questions triviales ("j'ai pas les droits sur tel répertoire, je dois faire quoi?") explose dès le début des périodes de stages..

pip, et plus simplement le packaging python, a été une vraie galère à mettre en place. C'est fait pour des lib, pas pour des outils (genre les fichiers de conf par exemple) :(

Sinon en fait le paramètre à 0 est situé juste en dessous de use_ssl avec un texte très explicite, donc là sincèrement le mec qui active le ssl ne pourra pas dire qu'il ne l'a pas vu :)

Ce qu'il faut voir c'est que si je le passe à 1 par défaut, on va avoir une armée de stagiaires arriver en pleurant sur les forums qui ne vont pas comprendre pourquoi ça ne marche pas, et sincèrement j'ai autre chose à faire que gérer une armée de stagiaires en supervision :)
(oui je commence à les connaître ceux là au bout de quelques années dans le domaine :) )

Là le paramètre est très clair, commenté et juste ne dessous de l'activation du ssl, donc un admin "normal" n'aura aucun soucis à savoir qu'il doit le passer à 1 s'il a ses propres certificats.

Bon après sincèrement autant mettre un simple reverse apache/nginx en façade, car les admins ont déjà tout outillé pour ça (les règles puppet and co) et ça facilite un peu la mise en place sur de grosses infras un peu sensibles au point de vue réseau (genre là où on a mis la 2.0 en prod dernièrement en fait).

On verra bien comment ça sera utiliser au final, après tout vu que c'est du http, c'est très malléable :)

Et hop voici une 2.0.1 toute chaude avec le paramètre de géré sur tous les daemons. Pour info il faut donc rajouter le paramètre hard_ssl_name_check les configuration des daemons (en plus de use_ssl donc).

Pour mettre à jour un passage par la commande pip suffira :)

Finalement heureusement que l'update simplifiée est gérée dès à présent :p

C'est justement pour ça que je prépare la 2.0.1 :)

Cette version est surtout concentrée sur le http, le s était en plus, car les mise en prod que j'avais faite reposaient surtout sur des reverse proxy qui s'occupaient de ça en frontal (car il le faut de toute manière pour la partie web), d'où le manque sur ce paramètre là. faut dire qu'entre les nrpe t autre graphite en général en matière de supervision on a d'autres soucis que le chiffrement (ou plutôt authentification) mais bon ça n'excuse pas tout en effet :p

Sinon pour pre shared key je connais le principe, c'est juste que j'aimerai surtout savoir ce que ça donne en vrai dans openssl côté implémentation et si possible si c'est déjà géré par pyopenssl (mais ça ça ne doit pas poser un gros soucis).

Ah intéressant, elle permet quoi exactement? Si elle est pas trop impactante (car si beaucoup ont encore du mal à avoir une vrai PKI :) ) ça pourrait être pas mal :)

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 :)

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

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 :)

Je confirme que tu as mal compris :)

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

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) …

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 nation^{Winternational.} 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 :)

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.

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

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 :)

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