Un logiciel est considéré comme « libre » si il est publié sous une licence libre (GPL, BSD, etc.) mais à mon humble avis ce n'est pas suffisant. En effet, si l'on se contente de fournir le code source dans un tar.gz sans utiliser de dépôt public et sans Changelog, est-ce que cela donne véritablement la liberté de l'étudier ? Sans l'historique des commits, est-ce que cela permet facilement d'écrire un patch ?
Un Logiciel Libre doit pouvoir être étudié et modifié, et je pense que cela implique :
- d'avoir dépôt public
- de rédiger des messages de commit clairs
- d'avoir un bug tracker public
- d'avoir des canaux de communication publics (IRC, listes de diffusion)
- de publier la Roadmap
- de faciliter la contribution (contributing guidelines)
Cela paraît évident pour beaucoup, et j'oublie sûrement des critères, mais l'idée générale est qu'un Logiciel Libre doit favoriser la contribution. Il y a trop d'entreprises qui agitent les termes "Logiciel Libre" et "Open Source" sans encourager la collaboration…
Dans cette optique, un élément important pour inciter les contributions est d'ouvrir au plus tôt les outils, que cela soit transparent dès le début, permettant ainsi aux personnes intéressées de donner des idées, de reporter des bugs, d'écrire de la documentation, de traduire, de contribuer au code, etc.
Il y a quelques mois, Jéremy Lecour et moi avons eu l'idée de créer un Logiciel Libre pour surveiller les expirations de noms de domaine et de certificats SSL. À l'heure de l'explosion du chiffrement SSL/TLS, détecter l'expiration des certificats est important (cf l'incident récent sur linuxfr). Et pour les noms de domaine, quand vous avez plusieurs registrars, il est pratique d'avoir une centralisation des dates d'expiration et des notifications sur mesure.
Après discussions, on a fixé le cadre de ce projet : se baser sur les informations publiques (requêtes TLS, WHOIS), avoir une interface web, permettre des notifications avancées par email et faire un « vrai Logiciel Libre ». L'objectif est de créer un logiciel simple et ergonomique, qui permette d'avoir des installations publiques utilisées par plusieurs utilisateurs.
Le projet a débuté il y a quelques jours, nous avons fait les premiers choix techniques, comme l'utilisation de Ruby on Rails ou la licence AGPLv3, et passé quelques heures à écrire les premières lignes de code. Ça n'est évidemment pas utilisable pour l'instant mais dans l'optique expliquée plus haut nous voulons rendre transparent dès le début cet embryon de projet et encourager les contributions !
Le dépôt et le bug tracker : https://github.com/Evolix/chexpire
Canal de communication : IRC #chexpire sur Freenode
Roadmap (en cours de rédaction)
# Mouais
Posté par kursus_hc . Évalué à 10. Dernière modification le 05 juillet 2018 à 02:32.
Avant de répondre :
Oui. C'est sans doute moins facile à exécuter/étudier/modifier/distribuer mais ça n'en fait pas pour autant un logiciel moins libre.
Du coup, principalement à cause du ton et de la mauvaise compréhension des termes, la longue intro du journal est difficile à lire (oui, on peut tout à fait agiter les termes "free software" et "open source" sans encourager la collaboration, les deux définitions principales ne mentionnant rien de plus qu'un code non offusqué pour être accepté) et on n'apprend pas grand chose à part que les bonnes pratiques c'est cool et que la collab' c'est in.
Puis on comprend pourquoi ce concept est important, si important qu'il mériterait même une réécriture majeure des définitions sur lesquelles tout le monde est d'accord, c'est parce qu'il permet, pardi, de faire bosser les autres à votre place !! Il vous suffit juste de
quelques heures à écrire les premières lignes de code, d'un Github (non libre), d'une licence introuvable sur le repo malgré un ticket vieux de 6 semaines, d'une roadmap famélique, dans un langage en perte de vitesse, bref de rien du tout de ce que vous avez énoncé en intro, sur un thème qui n'a de toute façon rien à voir avec, et tout ça pour, non ce n'est pas une blague, un truc qui n'est "évidemment pas utilisable pour l'instant".A mon humble avis le vecteur le plus fort pour entraîner la collaboration, sans compter la volonté, c'est le travail fourni en amont, pas la publicité préventive. C'est toujours bien de se motiver à faire un truc mais il faut que vous ne comptiez sur personne d'autre que vous pour sortir quelque chose d'attrayant, surtout quand on voit la qualité générale des projets qui sont postés en journaux.
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à -2.
Merci d'avoir pris le temps de répondre et de jeter un coup d'œil au dépôt.
Mon « introduction » sert à souligner que lorsque les bonnes pratiques ne sont pas appliquées, cela revient à une sorte d'obfuscation du code. Évidemment cela ne remet pas en cause la liberté d'un point de vue légal / application littérale des définitions.
Ensuite, ton interprétation « vous écrivez quelques ligne de code, et vous espérez que l'on bosse à votre place » n'est pas très juste. On ne compte pas se tourner les pouces, et une version utilisable sera disponible dans quelques jours. Quand à la licence, elle disponible dans la branche add-license.
[^] # Re: Mouais
Posté par Sytoka Modon (site web personnel) . Évalué à 10. Dernière modification le 05 juillet 2018 à 07:18.
Moi aussi votre baratin m'a gêné. Vous faites du libre, ok, mais pas besoin de ré-écrire ce que c'est le libre selon vous. Je fait moi aussi du libre, j'ai mon propre dépôt accessible sur le net. Je ne fait aucune pub ici et je ne vais pas sur le réseau social github. Mais cela n'est pas moins libre.
Pourquoi des plus et des moins ?
En plus, c'est vrai que le coup de ne pas avoir de licence dans le master et de lancer un projet qui a déjà 36 branches, c'est sur que cela aide la contribution et rend le projet plus libre… Stop à la multiplication des branches qui nuisent à la compréhension d'un code. C'est presque de l'offuscation de code ;-)
Bon courage
PS : en ce qui concerne les certificats, il y a un greffon Nagios qui teste les certificat TLS et lève un drapeau. Il fonctionne parfaitement.
[^] # Re: Mouais
Posté par oau . Évalué à 4.
pareil dans xymon. Très simple. Il suffit de monitorer une url https. Et par défaut. Il me semble que c'est vraiment une fonctionnalité basique que de monitorer l'expiration d'un certificat ssl.
https://www.xymon.org/help/manpages/man5/hosts.cfg.5.html section "http tests"
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à 1.
Merci d'avoir mentionné Xymon, c'est intéressant de voir leur check HTTPS qui permet de faire un check basique d'expiration avec ssldays=WARNDAYS:ALARMDAYS
L'idée de Chexpire est de ne pas être dépendant d'un Nagios/Icinga/Xymon pour ces checks et d'avoir une interface web conviviale pour rajouter des domaines / notifications.
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 6.
Est-ce pertinent? Je veux dire, tout sysadmin digne de ce nom a un outil de monitoring, peux-tu expliquer en quoi un outil à part (maintenance, UI différente…) est utile pour un sysadmin? Jusqu'au découper? pour chaque module Nagios tu penses qu'il faudrait un outil dédié?
Ca manque d'argumentation et d'explication sur l'idée derrière le projet… Avant une roadmap, il faut savoir quels sont les objectifs d'un projet, ça fait charrue avant les boeufs.
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à 1. Dernière modification le 05 juillet 2018 à 14:41.
Le « public visé » n'est pas le sysadmin qui va souvent préférer mettre en place son Nagios/Icinga/Xymon/Zabbix ou scripts personnels mais plutôt les webmasters/développeurs/DSI/« décideurs pressés » qui veulent avoir une surveillance « de loin ».
Concernant les explications / argumentations, j'ai complété un peu via le commentaire 1743341.
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à 1. Dernière modification le 05 juillet 2018 à 09:54.
Le greffon Nagios check_http est super en effet, on l'utilise intensément sur nos serveurs. Chexpire va justement utiliser check_http pour faire ses vérifications régulières, on peut le voir comme une surcouche qui va permettre de centraliser tous ses sites à surveiller et avoir des notifications personnalisées (sans dépendre de Nagios/Incinga).
Ahah :-) Le workflow décidé pour l'instant est de créer une branche pour chaque feature puis de les merger dans master. C'est le workflow « à la mode » sur Github/Gitlab/etc. mais YMMV
[^] # Re: Mouais
Posté par Blaise . Évalué à 3.
Pourquoi conservé les branches mergées au lieu de les supprimer lors du merge ?
[^] # Re: Mouais
Posté par CrEv (site web personnel) . Évalué à 9.
C'est aussi que si les 15 branches déjà mergées étaient supprimés ça permettrait d'y voir plus clair. C'est justement le genre de chose qui ne donne pas vraiment envie de participer en fait…
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à 1.
Pour la suppression des branches mergées, on prévoyait de le faire de temps en temps, mais il n'y a pas vraiment de raison d'attendre, hop on est passé de 36 à 7 branches : https://github.com/Evolix/chexpire/branches
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 10.
NON.
Ca ne te plaît certes pas, mais le libre n'est pas ce que tu imagines (loin de là…).
kursus_hc t'explique pourquoi, mais tu insistes, ça en devient gênant.
Si le libre ne te plaît pas (tu ne sera pas le premier, genre "Licence Zero" que s'affiche / s'affichait comme ami avec le libre mais a fait rire les libriste car non libre en fait, ou des gens voulant absolument que du NC soit un peu lié au libre…), je te conseille plutôt de créer un nouveau mouvement.
Surtout après avoir balancé :
En gros, tu n'as pas passé beaucoup de temps dessus, pas mal de monde est capable de reproduire en quelque heures avec sa façon de voir, donc ça n'aide pas tant que ça.
Vaudrait mieux passer plus de temps sur le code que de faire de la branlette intellectuelle sur trouver une nouvelle définition que toi seule accepterait du libre, ça serait plus utile.
(oui, commentaire qui peut être vu comme agressif mais autant pourquoi pas se planter sur ce qu'est le libre une première fois, autant continuer dans cette direction qu'on on te dit que tu te plante devient énervant)
Pour des gens qui disent que le libre est important, faire la publicité d'une "première version" (87 commits, soit 87 "versions" en fait) non libre est juste comique. Quelqu'un qui pense que le libre est important pose généralement la licence dans son premier commit.
C'est malgré tout l'impression que vous donnez, surtout quand vous venez chercher du monde pour un logiciel non libre (à l'heure où j'écris, le logiciel est non libre, on a le droit de ne rien faire, absolument rien, vu qu'il n'y a pas de licence, du moins dans la branche principale. bon, après peut-être que quand une branche est dispo avec une licence ça marche aussi, mais perso dans le doute vu que ce n'est pas dans master j'éviterai de prendre le risque de l'utiliser, surtout quand on voit que la branche licence a 35 commit de retard et 25 jours sans merge alors qu'ajouter la licence prend quelque seconde le temps de faire le PR, on se dit que ça cache quelque chose).
Sinon :
Oui, le code est la et c'est largement suffisant (et perso, quand j'étudie un logiciel pour le patcher, je regarde que très rarement le log, c'est le code actuel qui m’intéresse, ça sert dans de rare cas genre pour savoir depuis quand un bug de sécurité est la).
Oui, rien à voir (ni avec la difficulté d'écrire un patch, ni avec le libre)
Toute la liste qui suit n'a absolument rien à voir avec le libre, mais plutôt avec le communautaire. Mélanger les deux montre une grosse incompréhension sur le libre (on peut être non libre et communautaire, ou libre non communautaire), il faudrait commencer par se documenter sur ce qu'est le libre avant d'essayer de changer le libre.
Il y a des dizaines de projets de la sorte déjà disponibles (et en libre, et en connu genre plein de plugins pour des plateforme de supervision, je ne suis pas sysadmin donc ne connaît pas les noms par cœur mais de tête mon sysadmin a utilisé un plugin), qu'est-ce que le votre apporte de plus?
C'est sur ça (dire ce que vous apportez au libre) qu'il faudrait se pencher en priorité après la licence.
Le bonnes pratiques non appliquées concerne le logiciel présenté (ne pas mettre de licence dans les premiers commit est une très mauvaise pratique).
Vu le coté chaotique du journal (branlette intellectuelle sur le libre qui n'a pas été compris, logiciel non libre dans la branche master… Le tout dans un seul journal pour 2 sujet différents), je pense que vous vous êtes bien cramé pour motiver des gens à venir (voir cramé sur d'autres choses…).
bon, maintenant que vous savez (si vous ne saviez pas avant, ce qui est déjà gênant), est-ce que vous changerez de façon de communiquer et de faire du logiciel (libre ou pas) ou continuerez à troller sur le libre? Pour le moment un journal qui mélange tout, et un commentaire qui montre ne pas vouloir comprendre le problème, peu glorieux.
(bon, café fini, passons à autre chose…)
[^] # Re: Mouais
Posté par Samuel Verschelde (site web personnel) . Évalué à 4. Dernière modification le 05 juillet 2018 à 09:43.
Je vous trouve bien négatifs vis à vis de ce journal.
On ne va pas passer des années à discuter sur ce qu'est le libre ou ce qu'il n'est pas. Certes, la publication seule des sources avec une licence libre rend un logiciel libre au sens légal, mais c'est souvent du libre du type "boîte X ayant 100% de la maîtrise de son code, ne comptant pas faire participer la communauté, ayant peur des forks et souhaitant juste bénéficier de l'aura de l'open source". Les process exacts de build sont souvent non publics, d'ailleurs, dans ces situations. Je peux comprendre qu'on ne considère pas ça comme "vraiment libre", non pas du point de vue légal, mais du point de vue du respect d'un esprit du libre.
Bon, d'accord, l'introduction de ce journal m'a moi-même semblé enfoncer des portes ouvertes sur ce site où la notion de logiciel libre est une évidence, et j'aurais préféré une simple présentation du projet et invitation aux contributions pour ceux que cela intéresse, mais bon sang un peu de bienveillance sur ce site ne ferait pas de mal !
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 8.
une des choses qui fait le plus mal au libre est que des gens viennent balancer que c'est pas dans l'idée du libre si ce n'est pas communautaire, exactement comme la phrase que je cite.
Mais même au niveau de l'esprit ça n'a rien à voir, tu montres que tu n'as pas lu le commentaire auquel tu réponds, je t'invite à le lire si le libre t’intéresse plus que l'idée que tu veux du libre.
Note que j'ai réagit au commentaire, et non au journal, pour la simple raison que la personne persiste dans son mélange, sans essayer de comprendre le soucis. comme d'ailleurs le message auquel je répond maintenant : non, dire des choses hors sujet sur des obligation en libre (légal ou même dans l'idée) n'aide pas le libre, il le limite même (ça fait juste faire peur aux gens de devoir faire du taf en plus si le code est libéré, alors que ça n'a rien à voir, le libre s’intéresse à ce lui qui reçoit du code, lui fournir le code source correspondant et rien d'autre, pas de taf en plus comme ce qui est demandé par l'auteur du journal et l'auteur du commentaire auquel je répond).
L'auteur du journal (et du commentaire auquel je répond) veut libre et communautaire, soit. Qu'il le dise clairement, plutôt que de faire croire que le libre nécessite du communautaire (dépôt public, tracker public etc n'ont rien à voir avec le libre, suffit de lire les 4 libertés du libre pour comprendre que c'est hors sujet) en essayant de redéfinir le libre.
OK, mais bon avoue que c'est quand même pas facile lorsqu'un projet est inutilisable et sans licence (donc non libre), ne plus d'être redondant (l'auteur a "oublié" de dire en quoi son projet est différent de dizaines d'autres, "Yet Another SSL checker").
[^] # Re: Mouais
Posté par Graveen . Évalué à 6.
Tu veux dire que selon la réaction, on va voir si ce sont 2 hipsters qui se tripotent dans leur "agence", ou non ?
:D
Comme ci-dessus, ca fait un peu "j'ai une idée je vais vous laisser bosser dessus".
Les points soulevés relèvent de l'évidence ("les bonnes pratiques c'est bien") mais les conclusions sont vraiment discutables ("c'est ce que doit faire un logiciel pour etre libre").
Et de toutes façons, chaque projet a sa propre organisation, du coup vous pourrez appliquer vos propres règles.
[^] # Re: Mouais
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Je suis surpris. Quel est l'intérêt de faire ça dans une branche à part ?
Sinon, ce n'est pas un peu trop pour encourager les contributions alors qu'il n'y a pas encore de guide de contributions ?
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à 1.
Le workflow décidé est de créer une branche pour chaque feature et de les merger ensuite dans master.
Il reste quelques ajustements à faire concernant la licence, donc elle n'est encore mergée.
Bonne remarque pour le guide des contributions, on va le faire rapidement
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 8.
Le journal dit le contraire : "nous avons fait les premiers choix techniques, comme (…) la licence AGPLv3" (à noter que le choix de la licence n'a rien à voir avec la technique mais plutôt sur la gouvernance d'un projet; mais c'est un détail).
Du coup, tu en rajoutes une couche, en disant une chose (choix fait) puis son contraire (choix non fait), perso tu fais plutôt fuir les contributeurs potentiels avec ces incohérences.
Si tu as fait le choix de l'AGPLv3, tu ajoutes clique sur la case license dans GitHub, tu sélectionnes AGPLv3, et accepte le commit, réglé (en bonus ensuite tu peux ajouter le licence dans les fichiers sources, mieux mais plus un détail), tout "il reste blablabla" dit que tu ne veux pas faire de libre.
A noter que ta branche existe en ligne, une personne qui voudrait utiliser en libre pourrait tenter de dire que la branche est libre et forker à partir de la branche, tu es limites en légal (entre "AGPLv3" et "rien", ça dépend de la branche, compliqué), une bonne pratique pour du développement est d'éviter ce genre de truc bizarre.
Tu parles "lorsque les bonnes pratiques ne sont pas appliquées, cela revient à une sorte d'obfuscation du code." et tu es le premier à ne pas faire de bonnes pratiques, ne faudrait-il pas commencer à appliquer les bonnes pratiques de base à ton projet avant de faire des plans sur la comète?
[^] # Re: Mouais
Posté par Gregory Colpart (site web personnel) . Évalué à -2.
L'ajout de la licence dans les fichiers source n'est pas un détail. C'est important pour le packaging (création d'un paquet Debian par exemple) et encourager la ré-utilisation d'une partie du code dans d'autres projets.
Sinon, merci pour tes conseils, on travaille pas mal dessus cette semaine (à la fois sur le code et les « bonnes pratiques ») et les remarques/critiques/idées relevées ici sont instructives !
[^] # Re: Mouais
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 05 juillet 2018 à 15:32.
Excuse bidon pour ne pas mettre de licence :
- l'interface GitHub fait un truc "standard" pour le fichier licence, donc compréhensible par tous.
- Absolument rien ne vous empêche d'améliorer ensuite la partie licence (en mettant un header dans les fichiers source etc…)
Assumez si vous ne voulez pas faire de libre, ne vous cachez pas derrière des excuses "rigolotes" pour diffuser aujourd'hui du non libre.
Sérieux, les bonnes pratiques de base est de mettre un fichier de licence, bien avant tout ce qui est listé dans le journal, on a beau vous le signaler 36x vous refuser d'écouter, mais vous parlez toujours de vouloir faire une communauté. Arrêtez tout et prenez ces 2 minutes maintenant pour cliquer sur le bouton Licence de GitHub et basta, si vous voulez être un minimum crédible sur le libre.
Juste pour info au cas où les bonnes pratiques vous intéressent, perso l'un des premier commits que je met dans un repo est la licence et la première ligne que je met dans un nouveau fichier source est la licence; aucun code source sans licence, point, et si il y a un oubli on le corrige de suite (genre en cliquant sur le bouton Licence de GitHub). Vous avez vos priorités, pas la peine de dire que le libre est important pour vous si c'est la dernière chose que vous voulez faire.
La, au fur et à mesure des réponses, vous collectionnez toutes les mauvaises pratiques à la fois sur le libre et sur le communautaire, je crois que le plus urgent n'est même pas de mettre la licence, mais de comprendre comment fonctionne une communication envers des utilisateurs ou contributeurs potentiels.
[^] # Re: Mouais
Posté par arnaudus . Évalué à 7. Dernière modification le 05 juillet 2018 à 14:00.
Bah, déja, il s'agit des «bonnes pratiques» selon tes critères, qui ont l'air pour le moins douteux. D'autre part, ça me semble complètement faux. Si tu télécharges le tar.gz d'une version stable, tu as le code, bien organisé dans des répertoires, la doc, la licence, les fichiers qui permettent la compilation et l'installation. Tu peux lire le code, tu peux l'étudier, tu peux le modifier, le partager. Bref, toutes tes libertés sont respectées. Ce que tu n'as pas forcément, c'est l'historique du logiciel, les vieux bugs qui ont été corrigés, les dates auxquelles le code a été modifié. Mais tu t'en fous, non? Quand on dit «étudier le code», on parle de comprendre la manière dont le logiciel fonctionne. Personne, à ma connaissance, n'a jamais considéré qu'il s'agissait de comment le logiciel est arrivé à la version actuelle—là, c'est plutôt du ressort des sciences humaines, ou éventuellement de l'étude historique pour des logiciels phares, comme le noyau Linux.
[^] # Re: Mouais
Posté par Marotte ⛧ . Évalué à 3.
Si le libre n’impose pas ce que tu nommes avec de justesse « bonnes pratiques », que l’on pourrait aussi rapprocher de la politesse ou de la générosité, ce n’est pas seulement, pour forcer le trait, une « liberté d’être un connard ». C’est un droit des plus primordiales de coder sans faire de documentation ! :)
Si un programmeur brillant écrit des programmes utiles et performants les uns après les autres, on va l’empêcher de commencer à travailler à plein temps sur son projet F, parce qu’il n’a pas fini la doc et le script d’install de son projet E ? Ça s‘applique de la même manière avec une équipe ou une communauté de programmeurs, une entreprise.
Je pense qu’il y a toujours quelque part l’espérance d’obtenir de l’aide quand on publie un code source, on ne ferait pas du libre sinon…
C’est toujours mieux de publier (et surtout promouvoir) quelque chose de fonctionnel mais tu fais bien de publier quand même.
C’est marrant… j’ai écrit un plugin Nagios il y a quelques jour pour faire ça :) Je ne l’ai pas publiée puisque j’ai fait ça au travail et que ce n’est qu’un truc trivial avec curl… mais si je dois en faire un outil plus utile je ferai un fork pour le publier pour tout le monde… ce que je ne compte pas faire cela dit, donc p-e que je jetterai un œil à ton produit qui sait :)
[^] # Re: Mouais
Posté par Arkem . Évalué à 6.
Est-ce que quelqu'un a une idée de ce qui fait la chute de Ruby de cette façon ? Est-ce que Python se maintient parce qu'il évolue mieux, ou juste parce qu'il est très répandu ? Ou est-ce que Javascript est en train de tout avaler ?
Ça m'intéresse, car je débute en Ruby dans le but d'en faire une boîte à outils avec RAILS pour des projets perso, et je peux encore me tourner vers Python + Django… Le fait que Ruby ne soit pas très répandu ne me gène pas vraiment, mais s'il cesse d'évoluer tandis que les autres se mettent au goût des nouvelles technos, c'est plus ennuyeux…
[^] # Re: Mouais
Posté par Bruno Michel (site web personnel) . Évalué à 8. Dernière modification le 05 juillet 2018 à 09:53.
Python + Django ne s'en sort guère mieux que Rails. Python a plus la côte que Ruby, mais c'est surtout sur des domaines autres que le web. Par exemple, les data scientists l'aiment bien pour ses bibliothèques telles que panda et numpy.
Pour le web, la mode est aux applications dites « Single Page Apps », avec beaucoup de logique exécutée dans le navigateur. Côté serveur, on trouve de plus en plus de trucs qui ne demandent quasiment pas de code (serverless, firebase de Google) même si ça reste encore une minorité pour le moment. Et à l'opposé, on trouve aussi beaucoup de bases de code très importantes côté serveur, avec plein de microservices.
Ruby et Rails sont encore utilisés, plus aux États-Unis et surtout au Japon qu'en Europe. Ça continue d'évoluer. Par exemple, Stripe travaille sur un outil, Sorbet, pour introduire de la vérification de typage. Il y a également l'objectif 3x3 qui avance. Ceci dit, c'est clair que Ruby n'a pas du tout les mêmes moyens financiers et le même nombre de contributeurs que JS, Go, Swift, etc.
[^] # Re: Mouais
Posté par Arkem . Évalué à 4. Dernière modification le 05 juillet 2018 à 18:48.
Bon, à priori, ça devrait suffire à mes besoins, du moment que le langage n'est pas à l'abandon
N'étant pas développeur, je préfère quelque chose d'un peu ancien qui utilise des techniques bien connues et qui ne nécessite pas une trop grosse machine pour tourner en premier lieu. Je vais poursuivre dans cette voie pour le moment…
Merci pour ces explications
[^] # Re: Mouais
Posté par arnaudus . Évalué à 10.
J'ai l'impression que le meilleur conseil à donner, c'est 1) stop à la branlette intellectuelle sur le libre, qui est à la limite du ridicule, et 2) décrire factuellement le logiciel, ce qu'il fait, comment il le fait, sa licence, et voila.
Pour le délire sur le libre, ça fait un peu «j'ai lu deux ou trois trucs sur le libre et j'ai réinventé le monde», surtout qu'apparemment le dépôt n'a pas l'air d'être bien clean (licence commitée tardivement, multiplication des branches, etc). En fait, deux notions qui n'ont pas grand chose à voir sont complètement mélangées, le libre (basé sur la licence du code) et l'aspect communautaire (modèle de développement). Bon, bah une fois que c'est dit, tout est là, on peut avoir du libre communautaire, du libre non-communauraire, et du non-libre communautaire (par exemple les licences type NC). On a le droit de préférer le libre communautaire, mais bon, ça a déja un nom, et il serait quand même sacrément pédant de prédendre redéfinir ce qu'est le logiciel libre parce qu'on ne connait pas le terme de "communautaire".
Par ailleurs, le principe même du développement communautaire n'est pas forcément lié avec l'utilisation d'un logiciel de contrôle de version ; il existait déja des logiciels libres communautaires bien avant les forges logicielles (les patches étaient envoyée par email ou par d'autres méthodes, les bug-tracker n'étaient pas intégrés à la gestion des versions, etc). L'idée même de publier en permanence l'état de la version de développement n'est même pas évidente ; pendant longtemps, on ne trouvait pas forcément très malin l'idée de diffuser autre chose que des release, la version de dev étant réservée à une communauté de développeurs qui se cooptaient. Bref, la transparence absolue de l'historique des commits, je trouve ça un peu bidon ; on peut vouloir faire du libre communautaire sans pour autant vouloir forcément exposer le moindre détail du développement, qui n'ont aucun intérêt pour personne (sauf peut-être pour ceux qui veulent savoir à quelle heure tu te couches, si tu ne commiterais pas de temps en temps sur tes heures de travail, etc., bref, cette espèce de transparence quasi-pornographique à la Facebook dont la nouvelle génération se délecte sans comprendre la nécessité de garder pour soi ce qui n'a aucun intérêt à être diffusé).
# certificatemonitor.org
Posté par Carl Chenet (site web personnel) . Évalué à 10.
Bravo et bon courage pour la suite de votre logiciel,
Pour info un service en ligne basé sur un logiciel libre (agpl) existe : certificatemonitor
Je l'ai utilisé il y a quelques années et ça faisait le taf. Je le cite pour vous en inspirer si jamais il offre des fonctionnalités qui correspondent à vos besoins.
[^] # Re: certificatemonitor.org
Posté par Gregory Colpart (site web personnel) . Évalué à 4.
Salut Carl et merci du soutien :)
certificatemonitor n'était pas passé sous notre radar, donc c'est très intéressant… d'où l'intérêt de confronter l'idée très tôt à la communauté ! Il y a pas mal de points similaires visiblement donc on va s'en inspirer. Dans les points différents - outre d'intégrer l'expiration des noms de domaine - nous avons l'intention d'implémenter des notifications personnalisables, donc chacun pourra choisir quand il reçoit une alerte.
# Et en fait, ça fait quoi ?
Posté par Anthony Jaguenaud . Évalué à 7.
Le titre fait croire que tu parles d’un nouveau logiciel libre, mais dès les premières lignes tu nous explique ta vision du libre, et pourquoi ce nouveau logiciel est plus libre que libre. Mais concrètement, il fait quoi ce logiciel ?
[^] # Re: Et en fait, ça fait quoi ?
Posté par Gregory Colpart (site web personnel) . Évalué à 3.
La finalité est de surveiller l'expiration de noms de domaine et surtout de certificats SSL. Le principe est d'avoir une interface web qui centralise ses noms de domaine/certificats SSL et qui envoie des notifications, par exemple un email à J-30 sur todo@example.com puis à J-10 sur urgence@example.com.
Au niveau technique, l'idée générale est d'avoir un worker qui va tourner toutes les nuits et faire les vérifications via des requêtes WHOIS et des requêtes TLS pour récupérer la date d'expiration. Pour l'instant il va se baser sur les commandes whois et check_http (greffon Nagios) et parser la sortie. Ensuite, un 2ème worker va se charger d'envoyer les notifications en fonction de ce qui a été défini.
L'interface web permettra d'ajouter des checks facilement, de définir des notifications (pour l'instant par email, dans le futur probablement par SMS) et d'avoir une liste qui récapitule tous ses domaines surveillés.
[^] # Re: Et en fait, ça fait quoi ?
Posté par Anthony Jaguenaud . Évalué à 8.
Merci.
C’est dommage que ton journal ne commence pas par ça, car le petit paragraphe est noyé dans le reste.
[^] # Re: Et en fait, ça fait quoi ?
Posté par guppy . Évalué à 6.
Je vais être un peu abrupte mais après tout si tu postes ici c'est certainement que tu cherches des avis différents du tien : c'est complètement creux ton histoire.
Si je comprends bien c'est un simple wrapper au dessus de check_http ?
Ce que font déjà Nagios et ses dérivés / concurrents ? Sauf que eux :
* ils existent déjà
* ils sont déjà debuggés et probablement mieux conçus
* ils servent également à beaucoup d'autres choses.
C'est un peu comme si vous vouliez faire un super clavier pour taper des 'A'. Il y a certainement des gens qui tapent beaucoup de 'A'. Vous prendriez un clavier standard, vous vireriez tous les lettres qui ne sont pas des 'A' et vous effaceriez le 'A' sur la touche pour en redessiner un beaucoup plus joli. Qu'est-ce qu'ils seraient content les gars qui aiment les 'A'.
A côté de ça, bien évidemment, vous mentionneriez toutes les étapes, compte rendus de réunion, brain storming etc…, sinon ça ne serait pas du hardware libre n'est-ce pas ?
J'ai pas l'impression que ce soit l'idée du siècle pourtant ça ressemble à ce que tu présentes. Mais peut-être que vous avez raison et qu'ici on a tort. Le mieux pour tout le monde serait que vous fassiez ce genre de journal beaucoup plus tard. Les vraies bonnes idées n'ont en général pas besoin de publicité, en tout cas pas à ce stade.
[^] # Re: Et en fait, ça fait quoi ?
Posté par Marotte ⛧ . Évalué à 4.
Bah non clairement… C’est d’ailleurs pour ça que je suis proprement stupéfait par le nombre d’incidents liés à des certificats SSL qui expirent …
Je te rejoins sur Nagios1, si tu as ça sous la main c’est précisément son domaine de compétence de surveiller ce genre point et alerter. Ceci étant dit, un logiciel comme celui de l’auteur, s’il reste orienté SSL (avec p-e d’autres fonctionnalités connexes à l’expiration des certificats), qu’il offre une belle interface et est très facile à déployer, ça peut intéresser un SI qui galère à gérer ces certifs et qui a peu de ressource, pas de Nagios à disposition, un décideur pressé qui aime les belles interfaces et un techos qui aime la simplicité…
Je ne vois pas en quoi ce serait mieux pour tout le monde qu’ils s’abstiennent de publier et faire un appel à contribution… Au mieux des gens adhèrent au projet et les aides à le développer, au pire tout le monde s’en fout et pour eux c’est comme s’ils n’avaient rien publié/promu…
Certes c’est mieux d’avoir au moins une fonctionnalité quand on promeut un logiciel, et surtout quand on fait la leçon sur comment doit être un projet libre…
Moi je veux au contraire que ceux qui se lancent dans ce genre de projet communiquent à fond, parce que si le produit est mauvais on peut le savoir plus tôt, c’est mieux pour tout le monde. “Release early, release often.”
[1] J’utilise le terme Nagios comme un terme générique (Icinga, Shinken, etc…), je me demande combien d’entreprise utilisent le logiciel Nagios en tant que tel…
[^] # Re: Et en fait, ça fait quoi ?
Posté par Gregory Colpart (site web personnel) . Évalué à 3.
C'est davantage qu'un simple wrapper : l'idée est d'avoir une interface web simple et ergonomique pour gérer une liste des domaines/URLs à checker et des notifications en cas d'expiration. Nagios/Icinga/etc. est beaucoup plus puissant mais tu perds en simplicité si tu veux juste gérer la partie expiration.
Les « concurrents » sont plutôt Pingdom / updown.io (ils gèrent bien plus que l'expiration, mais c'est pour expliquer que l'enjeu est surtout sur la simplicité et l'ergonomie de l'interface web).
Pour être plus concret, voici un screenshot du dashboard de notre version alpha :
[^] # Re: Et en fait, ça fait quoi ?
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 06 juillet 2018 à 02:36.
Tu n’utilises pas déjà une solution comme Shinken ou Centreon pour avoir pensé à utiliser ce plugin ? Je pose cette question juste parce que je suis curieux de nature. On peut effectivement utiliser les plugins Nagios pour ce qu’ils sont, à savoir une collection de programmes de monitoring divers, qui respectent une norme (de fait seulement certes mais une norme tout de même et sacrément bien foutue…), sans « tout le toutim » d’une plateforme complète de monitoring, ni même ne serait-ce que NRPE, le serveur permettant d’exécuter ses plugins sur un hôte distant (il y a SSH pour ça)…
Tu utilises https://github.com/nagios-plugins/nagios-plugins ou un autre fork ?
Par ailleurs, si tu utilises Ruby, tu as sûrement une bibliothèque pour faire du HTTP. Ce serait mieux qu’appeler un programme externe ?
Pour le whois je ne sais pas trop… je ne connais pas du tout Ruby mais du côté de Python je n’avais rien trouvé qui ne fasse pas appel à la commande whois elle-même. D’ailleurs, les enregistrements whois n’ont pas un formatage bien normalisé, c’est une plaie à parser… Alors moi aussi j’en profite pour « promouvoir » mon code :) Deux ans déjà… Tiens d’ailleurs ce script n’est pas vraiment « prêt-à-l’emploi »…
[^] # Re: Et en fait, ça fait quoi ?
Posté par Gregory Colpart (site web personnel) . Évalué à 2.
On utilise bien la commande check_http disponible sur https://github.com/nagios-plugins/nagios-plugins (elle est notamment dans le paquet Debian monitoring-plugins-basic). C'est une commande qui peut très bien être utilisée indépendamment d'une plateforme de monitoring. Elle est très poussée et peut même vérifier un certificat SSL d'un serveur SMTPS, IMAPS, etc.
L'objectif est de récupérer une « simple » date donc pour l'instant on utilise ces deux programmes externes et on se concentre sur le reste. On n'a pas trouvé de bibliothèque qui fait ce que l'on veut et on ne voit pas l'intérêt de le faire pour le moment (il est possible que l'on soit limité et qu'on doive finalement le faire). L'enjeu pour la partie expiration de nom de domaine est effectivement de parser le résultat renvoyé par les serveurs WHOIS. On a donc commencé à écrire des parsers pour les extensions les plus utilisées : .COM/.NET/.ORG/etc. (Verisign), .FR/.RE/etc. (AFNIC), cf https://github.com/Evolix/chexpire/tree/master/app/services/whois/parser
[^] # Re: Et en fait, ça fait quoi ?
Posté par Marotte ⛧ . Évalué à 3.
Oui. Je m’en suis aperçu après avoir fait mon bricolage avec curl (et un peu grâce à ton journal !), j’ai eu le mauvais réflexe de pas penser à check_http tout de suite, et donc de partir sur du DIY avec bash+curl… Mais du coup mon script a quand même une fonctionnalité en plus :), il indique l’émetteur dans la sortie du plugin. Je vais quand même bien sûr utiliser check_http pour éviter de multiplier les plugins de supervision.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.