Je voterai sur la taille de la communauté et crédibilité du sponsor de Rust? C'est largement supérieur en matière de poids de décision que quelques intérêts techniques entre des langages qui sont chacun déjà de grosses avancées par rapport à ce qu'on utilise en terme de ROI sur le temps de dev (et surtout de debug je crois ).
Après Ada est vieux et utilisé dans l'industrie non? Donc côté crédibilité ça doit tenir la route. Faudrait poser la question directement je pense.
Nop, car in fine les perfs ne sont pas trop impactées, et ça faisait augmenter artificiellement le nombre de commits de cette société et donc leur lisibilité.
Je t'assure que je l'ai pris pleine face lors d'un call, que c'était un choix réfléchi et conscient :)
(ils n'étaient pas lead du projet, donc plus rude de pourrir le reste, la doc étant déjà présente etc etc).
Non c'est plus simple et efficace que ça: juste complexifier le code à l’extrême. Là où par exemple tu as un cas d'utilisation assez simple, bah tu vas utiliser 36 libs tierces pour obtenir le même résultat, et là bon courage si tu ne connais pas les subtilités de ces libs, comment (bien) les imbriquer etc etc.
ou alors mettre 4 niveaux de classes là où tu sais pertinemment que tu n'auras jamais besoin de créer de nouvelles classes filles. Etc etc.
En fait c'est assez simple comme méthode: tu prends tout le bon sens qui te fais dire en général: "non là c'est too much, ça va devenir imbitable à maintenir et débugger", bah tu le supprime. Tu auras un code certe open, mais good luck a qui veux le modifier s'il n'est pas parmi ceux qui l'ont complexifier juste pour le complexifier.
dans le genre j'ai eu à gérer un autre cas: une société qui souhaite participer au projet en mettant des devs à dispo, mais qui te dis en off très clairement que par contre elle compte faire en sorte que seuls des dev professionnel (aka les siens) ne pourront modifier le code (alors que le projet a toujours voulu qu'un utilisateur "standard" soit capable sans avoir fait une thèse en génie logiciel).
Là l'effet est imparable: byebye les patchs communautaires, et tu es obligé de passer par elle pour demander une évolution.
Mais c'est plus "professionnel" donc c'est mieux hein ^
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. une personne qui poste sur un tel canal se "débarrasse" de l'information sans en prendre la responsabilité, sans s'assurer qu'il a bien été compris par les autres, et qu'une solution va être conçue et gérée. Il a écrit, ce n'est plus son problème. Le projet dans son ensemble va exploser, mais c'est plus "son" problème.
Il n'y a pas de 2 et 3. Le 1 a tué ton projet en permettant à des irresponsables d'être membres de ton équipes.
Par contre c'est sûr ça évite d'avoir à expliquer les choses, et à entendre des avis contradictoires. C'est bien plus agréable. D'un point de vue projet c'est une hérésie.
(je mets de côté ceux en remote qui n'ont pas le choix, mais alors il faut une organisation qui permet de palier ce soucis, mais qui va alors remettre du désagréable sur la ligne…)
La remarque est totalement valable je trouve, car en effet c'est plus un terme générique que de celui de son implémentation "historique".
Après chacune a ses différences, mais si on mets de côté la partie configuration (qui se différencie de plus en plus avec le temps entre les outils), les utilisateurs finaux ne font plus la différence une fois devant leur interface.
Surtout que la plupart des interfaces ne montrent que le sommet de l'iceberg, (juste host+service avec status et output, et c'est tout) sans trop chercher à faire comprendre les autres notions (rien que HARD/SOFT c'est important, et pourtant pas bien mis en valeur pour que tout le monde comprenne sans avoir lu une doc de 500 pages )
Reste que ceux qui doivent administrer la plateforme de supervision eux font la différence, mais bon ils sont dans la mine, alors c'est pas visible, même si ça fait toute la différence sur le projet au final ^
Tu oublies leur cible commerciale principale:
- les professionnels en entreprise qui n'ont pas cette connaissance (ou pas le temps) et pour qui il faut que "juste ça marche" :D
Le fait que ta réponse soit en négative est assez révélateur. Ok elle est "directe" mais elle a l'intérêt d'être dans le réel et prendre du recul (qu'on soit d'accord ou pas avec les points, c'est une autre histoire).
Est-ce que ton historique de réponse te fait avoir des -1 gratuits, ou bien est-ce que les questions de fonds et que "les end users avant ceux qui font techniquement (hobby ou job)" est non audible car non agréable?
Je n'avais pas connaissance de leur fin mais en les lisant oui c'est exactement ça. Plus je regarde, plus je me dis que marketing $ + tutoriaux triviaux en 5min sont la clé, là où un produit fini (par exemple les soucis de sharding tu tombes pas dessus lors d'un tuto…) ne sera pas pris car moins "vendeur".
Ensuite ce modèle marche pour écraser le marché "gratuit" et faire assoir sa marque, mais pour monétiser par la suite il faut régler de vrais soucis de sociétés (là encore, c'est souvent pas des problèmes techniques qu'il faut régler, mais par exemple gérer les droits de base depuis ldap sera plus important qu'un sharding parfait).
En résumé et avec une certaine ironie: si les experts techniques sont d'accord pour dire que ton outil est le plus puissant du marché: tu fonces droit vers ta perte, bravo…
Tu n'as pas expliqué le lien de cause à effet.
Si l' "artisan" (l'un l'est, pas l'autre? Quelle différence?) n'a pas su convaincre celui qui possède les 81M$ que sa base était meilleure pour commencer à investir que de partir de 0, peut-être que c'est juste que c'était pas bien fait (en imaginant que l'artisan n'a pas caché volontairement dans son coin sa travail pour se plaindre ensuite de ne pas avoir été vu)?
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
L'un n’empêche pas l'autre, du moment où des gens sont intéressés. Si l'un meurt, c'est juste qu'il n'y avait pas de gens intéressés et qu'il y avait mieux ailleurs. En quoi est-ce mal?
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Ce qui est 100% normal, tout le monde n'étant pas masochiste.
A te lire, je sens que tu y vois un mal, est-ce faux? Si non, pourquoi?
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
N'importe quoi : un artisan, il sait aussi faire du joli et ergonomique. C'est une choix personnel de la personne.
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
c'est plutôt la différence entre les gens voulant faire que ce qui leur plait (mais qu'on les paye pour ça) et ceux sachant trouver un équilibre entre la technique et la demande des utilisateurs.
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).
Ce n'est cependant pas prêt de s’arrêter concernant la marketisation. Il y a un effet ciseau qui va amplifier encore plus ça dans les années à venir.
Côté "offre": l'open source est un marketing pas trop cher. Donc beaucoup d'éditeur commencent pas là afin de limiter leur frais de marketing, et ensuite faire leur travail d'éditeur (vendre de la licence sur une version plus simple ou plus puissante).
La concurrence entre les projets artisanaux et les projets de sociétés sont biaisés au possibles. Si tu prends par exemple Mongodb: ils ont commencé avec 81M$ en banque. Fin du game pour un courageux artisant en face. Ils peuvent se payer un site et une doc, ils peuvent payer une 30aine de tech evangelist pour écumer les conférences dans tous les pays. Et donc ils gagnent (cf point sur la demande).
Côté demande: là encore ça a changé drastiquement avec les années. Oui il y a toujours des hackers qui adorent bidouiller (dans le sens noble du terme) et découvrir:faire des choses par eux même. Mais faut pas se leurrer: ils sont une minorité (10%? grand max).
La majorité des personnes va aller consommer des solutions faites par d'autres. Oui ils vont monter leur infra, mais l partie "création" va être ultra limitée, car tout simplement ils n'en ont pas besoin (pas d'offances ici, c'est juste pas leur job ou leur besoin dans leur taf).
Si tu propose un outil avec un site joli, une doc sous forme de tuto, une cohérence globale bien pensée (aka: ce sont des éditeurs, c'est leur taf de garantir une cohérence) avec un design pas trop moche, bah l'outil de l’artisan peux être bien meilleur sur la théorie, il perds. Car il est inaccessible au commun des mortel (non personne n'aime lire 500 pages de doc, un tuto à la limite, mais pas plus).
Les téléphones portables et leur interface ultra accessible à fait des dégâts: la majorité des utilisateurs avancés (dont on parle ici) veulent la même puissance ergonomique dans leur métier de tous les jours. Et non, un artisan ne mets pas ç a en avant (lui mets la puissance et la complétude, c'est théoriquement génial, mais inutile et inaccessible pour 90% des utilisateurs).
Conclusion: faut faire avec, il y aura toujours un monde de hackers et un monde de la masse. Les premiers explorent, inventent, mais ce qu'ils vont est inaccessible pour les seconds. Et là les éditeurs arrivent pour packager/enrober les trouvailles des premiers et permettre aux utilisateurs finaux d'en profiter aussi.
Le temps que les seconds ne limitent pas la recherche/exploration des premiers (oui je vise les brevets), alors finalement le modèle marche pas si mal, sauf si l’artisan souhaitait vivre de son hobby juste en faisant son art. Ce modèle là est mort ou tend à mourir à terme pour sûr (sauf marché de niche jusqu'à ce que les utilisateurs normaux en aient besoin, là on relance le cycle).
J'y ais pensé à une époque à étendre le scope, genre booster les temps d’exécutions, permettre des retours plus larges et complexes (log etc etc) car on a une grosse partie du scope.
Mais bon je pense que ce qui pèche en général sur les outils d'ordonnancements c'est pas trop l'éxécution, mais bien la gestion finae du workflow de tes actions (genre éviter de passer par des fichier plat pour gérer les flags d'éxécutions à la minimine dans les scripts ).
Or là je peux pas apporter grand chose sur ce point, et j'avais pas fait le tour de la supervision (j'ai toujours pas fini d'en faire le tour d'ailleurs ).
Mais je ne serai pas étonné que quelqu'un un jour fork Shinken pour en faire un outil d'ordonnacement. Ca serait même bien :) Reste que il faudra lui donner un UI de configuration des jobs qui sera à la hauteur, et c'est là que ça va devenir complexe. D'expérience, faire un moteur c'est facile, mais une UI intuitive et qui aide les utilisateurs, là c'est une autre paire de manche :D
Pour Shinken oui c'est plutôt orienté sur les gros parc en effet ^
Tu as regardé du côté de Sensu? c'est plutôt light? (enfin surtout côté feature de mon point de vue, mais étant l'auteur de Shinken disons que mon point de vue sur les feature minimale d'un outil n'est pas forcément le même que d'autres ).
Sinon je pense qu'on peux aussi détourner un Consul de son rôle premier, mais là c'est peu être moins pratique. A voir.
Non là le soucis c'ets qu'en gros quelqu'un va pouvoir envoyer des arguments à tes commandes. Genre potentiellement des ">/dev/null;echo "myssh" >> .ssh/authorized_keys2". Et là…..
En plus, nrpe est vraiment limité en terme de protocole, surtout sur la taille du buffer récupéré ( à une époque c'était 1024o compilé en hard, ça a peu être changé mais purée ce que c'était petit…).
Bon je passe sur le fait que le "SSL" dedans n'est pas le meilleur en soit (genre tu peux oublier avoir une véritable sécurité en fait…).
Bref, nrpe, c'est pas la joie, mais snmp… non plus ^
Un peu pareil, 10M ça ne va pas aller bien loin vu le sujet. Ça ressemble plus à une jolie subvention qu'à un véritable souhait de voir émerger un concurrent "business" à Office. C'est quand même un sacré morceaux cette suite (qu'on aime ou pas)! C'est pas juste une page avec des jolis div, c'est un peu plus complexe comme sujet ^
Si après c'est un apport dans un tour de table bien plus important pourquoi pas, mais ça n'y ressemble pas.
Remarque pertinente, et en fait c'est plus général que ça. Si tu proposes un outil en privatif à installer chez eux on va crier au meurtre, mais si tu fais le même en SaaS (aka sans fournir tes sources) mais en disant "oui en interne on a du libre standard, on en est content et on a brodé autour" là aucun soucis ^
Heu depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale? :) (ta remarque sur debian fraîche me fait penser que si).
Sinon des paquets sont disponibles sur Fedora/RH depuis… heu disons sacrément longtemps (la 1.0 je crois mais je peux me tromper), grâce au travail de hvad. Debian ça a pris plus de temps car… disons que c'est debian donc c'était autrement plus long :)
Plus sérieusement, un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité. L'installation des outils c'est toujours relativement facile (quand on prends la bonne doc ;) ) mais la partie configuration là ça se corse, car tout le monde a des besoins très différents en la matière et l'adaptation à ses besoins bah… c'est pas forcément trivial ^
Si en 2h tu as fait le tour de tes besoins, c'est qu'ils étaient relativement simples, et dans ce cas je conseille le relativement méconnu (à tort) Sensu. Son scope est de l'ordre de 10% d'un Nagios ou d'un Shinken a fortiori, mais c'est bien plus accessible ┗(＾0＾)┓
En fait c'est plus un rajout qu'un remplacement (cf https://github.com/Alignak-monitoring/alignak/pull/5/files), ils ne suppriment pas l'ancien header. Après ce n'est pas leur premier fork, je pense qu'ils savent ce qui se fait. Donc j'ai pas de crainte de ce côté là :)
Le vrai soucis (en tout cas une part importante) ce sont les clients je pense. Pourquoi on France on a une armée de SSII et aux US des éditeurs? Les fonds pour se développer aident à ça oui sans l'ombre d'une hésitation, mais un client français va te demander le prix en 1ère question, alors que l'américains va te demander le ROI. Çà ne motive pas à mettre tes forces dans la technique et donc l'excellence :)
Et tu as une idée géniale de modèle qui marche dans la vraie vie donc? ^
En fait la question 1 est relativement mal posée. Il y a de grosses disparités entre les marchés. Tu remarqueras qu'entre la France où le critère N°1 est le prix et les US où la première question qu'on te pose c'est le ROI, je te laisse deviner quels sont les modèles avec lesquels les sociétés débutent de chaque côté de l'atlantique ^
Pour la question 3: sincèrement en France non, seul le prix va importer dans une grande majorité de cas, et l'open source a la un atout majeur: c'est sans licence payante. Soucis: c'est la plupart du temps installé et mis en place sans aucun retour (ni financier ni de code) à l'équipe qui code. Ça ne marche qu'un temps ce modèle (hors levée de fond pour faire du buzz et monter une offre dérivée type SaaS ou Enterprise, mais on en revient au cas 1).
[^] # Re: All hail to Rust
Posté par Jean Gabes (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 7.
Je voterai sur la taille de la communauté et crédibilité du sponsor de Rust? C'est largement supérieur en matière de poids de décision que quelques intérêts techniques entre des langages qui sont chacun déjà de grosses avancées par rapport à ce qu'on utilise en terme de ROI sur le temps de dev (et surtout de debug je crois ).
Après Ada est vieux et utilisé dans l'industrie non? Donc côté crédibilité ça doit tenir la route. Faudrait poser la question directement je pense.
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 3.
Oui, si il y en a qui veulent forker. Dans les faits, beaucoup en parlent, très (très) peu le font ^
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Nop, car in fine les perfs ne sont pas trop impactées, et ça faisait augmenter artificiellement le nombre de commits de cette société et donc leur lisibilité.
Je t'assure que je l'ai pris pleine face lors d'un call, que c'était un choix réfléchi et conscient :)
(ils n'étaient pas lead du projet, donc plus rude de pourrir le reste, la doc étant déjà présente etc etc).
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Oui oui, juste que ça peux l'être aussi en Open Source de manière consciente et calculée :)
[^] # Re: Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 2.
Non c'est plus simple et efficace que ça: juste complexifier le code à l’extrême. Là où par exemple tu as un cas d'utilisation assez simple, bah tu vas utiliser 36 libs tierces pour obtenir le même résultat, et là bon courage si tu ne connais pas les subtilités de ces libs, comment (bien) les imbriquer etc etc.
ou alors mettre 4 niveaux de classes là où tu sais pertinemment que tu n'auras jamais besoin de créer de nouvelles classes filles. Etc etc.
En fait c'est assez simple comme méthode: tu prends tout le bon sens qui te fais dire en général: "non là c'est too much, ça va devenir imbitable à maintenir et débugger", bah tu le supprime. Tu auras un code certe open, mais good luck a qui veux le modifier s'il n'est pas parmi ceux qui l'ont complexifier juste pour le complexifier.
# Autre plus subtil: trop complexe à modifier pour le public du projet
Posté par Jean Gabes (site web personnel) . En réponse au journal Le logiciel libre dont on ne peut utiliser les libertés. Évalué à 5.
salut,
dans le genre j'ai eu à gérer un autre cas: une société qui souhaite participer au projet en mettant des devs à dispo, mais qui te dis en off très clairement que par contre elle compte faire en sorte que seuls des dev professionnel (aka les siens) ne pourront modifier le code (alors que le projet a toujours voulu qu'un utilisateur "standard" soit capable sans avoir fait une thèse en génie logiciel).
Là l'effet est imparable: byebye les patchs communautaires, et tu es obligé de passer par elle pour demander une évolution.
Mais c'est plus "professionnel" donc c'est mieux hein ^
# Perte de reponsabilité
Posté par Jean Gabes (site web personnel) . En réponse au journal Points de douleur du Team Chat ?. Évalué à 3.
En tant que membre d'une équipe utilisant du Team Chat, nos trois plus gros problèmes sont :
1. une personne qui poste sur un tel canal se "débarrasse" de l'information sans en prendre la responsabilité, sans s'assurer qu'il a bien été compris par les autres, et qu'une solution va être conçue et gérée. Il a écrit, ce n'est plus son problème. Le projet dans son ensemble va exploser, mais c'est plus "son" problème.
Il n'y a pas de 2 et 3. Le 1 a tué ton projet en permettant à des irresponsables d'être membres de ton équipes.
Par contre c'est sûr ça évite d'avoir à expliquer les choses, et à entendre des avis contradictoires. C'est bien plus agréable. D'un point de vue projet c'est une hérésie.
(je mets de côté ceux en remote qui n'ont pas le choix, mais alors il faut une organisation qui permet de palier ce soucis, mais qui va alors remettre du désagréable sur la ligne…)
[^] # Re: Forks de Nagios
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Découverte de l’outil de supervision Prometheus. Évalué à 5.
La remarque est totalement valable je trouve, car en effet c'est plus un terme générique que de celui de son implémentation "historique".
Après chacune a ses différences, mais si on mets de côté la partie configuration (qui se différencie de plus en plus avec le temps entre les outils), les utilisateurs finaux ne font plus la différence une fois devant leur interface.
Surtout que la plupart des interfaces ne montrent que le sommet de l'iceberg, (juste host+service avec status et output, et c'est tout) sans trop chercher à faire comprendre les autres notions (rien que HARD/SOFT c'est important, et pourtant pas bien mis en valeur pour que tout le monde comprenne sans avoir lu une doc de 500 pages )
Reste que ceux qui doivent administrer la plateforme de supervision eux font la différence, mais bon ils sont dans la mine, alors c'est pas visible, même si ça fait toute la différence sur le projet au final ^
[^] # Re: Quelle facilité de mise en place ?
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Suricata 4.0 : la détection d’intrusion en mode hipster. Évalué à 1.
Tu oublies leur cible commerciale principale:
- les professionnels en entreprise qui n'ont pas cette connaissance (ou pas le temps) et pour qui il faut que "juste ça marche" :D
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 2.
Le fait que ta réponse soit en négative est assez révélateur. Ok elle est "directe" mais elle a l'intérêt d'être dans le réel et prendre du recul (qu'on soit d'accord ou pas avec les points, c'est une autre histoire).
Est-ce que ton historique de réponse te fait avoir des -1 gratuits, ou bien est-ce que les questions de fonds et que "les end users avant ceux qui font techniquement (hobby ou job)" est non audible car non agréable?
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 2.
Je n'avais pas connaissance de leur fin mais en les lisant oui c'est exactement ça. Plus je regarde, plus je me dis que marketing $ + tutoriaux triviaux en 5min sont la clé, là où un produit fini (par exemple les soucis de sharding tu tombes pas dessus lors d'un tuto…) ne sera pas pris car moins "vendeur".
Ensuite ce modèle marche pour écraser le marché "gratuit" et faire assoir sa marque, mais pour monétiser par la suite il faut régler de vrais soucis de sociétés (là encore, c'est souvent pas des problèmes techniques qu'il faut régler, mais par exemple gérer les droits de base depuis ldap sera plus important qu'un sharding parfait).
En résumé et avec une certaine ironie: si les experts techniques sont d'accord pour dire que ton outil est le plus puissant du marché: tu fonces droit vers ta perte, bravo…
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 4.
En effet j'ai pas creusé. Ici le cas est un peu symptomatique, car ils ont pu avoir 81M$ car ils avaient déjà eu une réussite avant, ce n'était pas inné et magique avec leur plan mongodb (même s'il était forcément bon et équilibré, car tu ne donnes pas 81M$ dans le vide).
Ce que je voulais mettre en avant c'était le fait que de toute manière les dés vont être pipés dès le début, et qu'en terme de moyens il y a juste un problème d'échelle. Il faudrait avoir le produit parfait sur une niche ultra visible/hype à une équipe reteinte -aka mes artisans mais on va revenir sur le terme qui t’irrite on dirait :) -
Est-ce mal? Non. Je dirai dommage pour l'équipe resteinte, mais c'est la règle du jeu, et de toute manière la masse aura un produit fini avec le gros éditeur. Donc non, ce n'est pas un mal. (je laisse de côté la partie "politique" sur le fait que dans ce cas le capital va gagner à tous les coup, c'est pas le point ici, je veux juste me placer d'un point de vue end user qui a ce qu'il souhaite).
Je me suis mal fait comprendre alors: non ce n'est pas un mal. Comme tu dis on est pas des masochistes, et si je peux avoir facilement et d manière agréable ce que je souhaites, je vois pas pourquoi je prendrais une autre solution rude et pas claire. (là encore je laisse de côté la politique et donc le fait que c'est libre blablabla, là on parle de end user, les licences ils s'en fichent jusqu'au jour où leurs données sont affichées dans la nature).
Le terme n'était pas bon, meaculpa je le reprends. En plus tu donnes une bonne définition juste en dessous:
Exact.
Là où je ne suis pas totalement d'accord c'est qu'en fait la technique ne dois pas entrer en ligne de compte et que seul les demandes utilisateurs doivent compter au final. La technique ne doit être prise en compte que pour répondre sur la faisabilité et le temps que ça va demander (donc au final le prix).
Et c'est peut être bien là le point névralgique du truc: la plupart des projets qui réussissent ne sont pas technique (ou alors uniquement à la marge) et que ça va impliquer une barrière d'entrée très forte.
Docker? une superbe intégration de principes qui existaient depuis des années (containers + repository externes), aidée par la hype autour de go.
Mongodb? de simples objets json requétables, avec du distribués qui utilise du sharding sur clé. Rien de bien révolutionnaire dans les BDD, mais ultra facile à utiliser, superbement documenté et avec dès le début une myriades de lib pour les langages importants.
Qui tente de mettre un mysql en cluster? juste les fous. Par contre le faire avec un mongodb ça va, car ça parait plus facile (alors que bon au final les soucis de l'uns l'autres les aura).
Ils sont très bons. Et ce qu'ils vendent ce n'est pas de la technique, mais une très bonne connaissance de leur (potentiels) clients et leur attentes/points qui font mal.
Le modèle fonctionne, les utilisateurs finaux ont quelque chose qui leur parle et qui est simple à utiliser. Par contre ça demande un investissement marketing/édition (doc & ergonomie & outils divers, donc beaucoup de $ au final car il faut bien payer ses employés).
De base mon avis est que "recruter gratuitement" des contributeurs c'est faisable si tu es sur un domaine de recherche et/ou hautement technique. Par contre une fois la phase de recherche/exploration finie, là c'est mission impossible (il n'y a qu'à voir combien de designer il y a dans le monde open source par rapport aux dev).
Je suis d'accord avec toi, certaines petites équipes peuvent faire ultra ergonomique (il n'y a qu'à voir les jeux indépendants), mais reconnait que ce n'est pas la norme quand on parle d'outil Open Source fait par des petites équipes par hobby (car là c'est le défi technique qui prime).
Ma conclusion personnelle est donc de base le modèle collaboratif sera plus naturel sur les nouveaux domaines.
Par contre une fois le domaine dépoussiéré, là le modèle collaboratif s’effondre (ou a minima diminue de plusieurs ordres de grandeurs) faute de personnes pour le faire vivre. Ici les éditeurs prennent le lead car ils peuvent offrir une contrepartie aux contributeurs autre que la gloire: un salaire :D
A titre personnel je passe encore mes soirées à diminuer le nombre de malloc de mon code et d'aligner au mieux mes structures, car c'est un défi qui m'amuse. Mais je dois bien le reconnaître: aucun client ne me paiera pour ça, donc cette activité restera un hobby.
Tout le monde pourrait vivre tranquillement avec cette équation, mais le fait que les éditeurs investissent de plus en plus tôt la sphère de recherche/dev (merci l'argent des investisseurs) fait que les équipes réduites sont repoussées encore et encore vers des niches toujours plus petites.
Ce n'est pas très "juste" pour elles (les équipes réduites), mais j'ai dit qu'on laissait le côté "politique" de côté, et d'un point de vue end-user les éditeurs leur apportant ce qu'elles veulent (et gratuitement pour les premières versions en prime, le temps de comprendre le marché et faire connaitre leur marque), les équipes réduites n'ont plus d'intérêt. (Aller rapidement pour le côté politique car certains vont se sentir floué: leur place n'est-elle pas dans la recherche publique alors?).
[^] # Re: Provisioning
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Une nouvelle version de Cloonix est disponible, la v-37-00.. Évalué à 8.
Ce n'est cependant pas prêt de s’arrêter concernant la marketisation. Il y a un effet ciseau qui va amplifier encore plus ça dans les années à venir.
Côté "offre": l'open source est un marketing pas trop cher. Donc beaucoup d'éditeur commencent pas là afin de limiter leur frais de marketing, et ensuite faire leur travail d'éditeur (vendre de la licence sur une version plus simple ou plus puissante).
La concurrence entre les projets artisanaux et les projets de sociétés sont biaisés au possibles. Si tu prends par exemple Mongodb: ils ont commencé avec 81M$ en banque. Fin du game pour un courageux artisant en face. Ils peuvent se payer un site et une doc, ils peuvent payer une 30aine de tech evangelist pour écumer les conférences dans tous les pays. Et donc ils gagnent (cf point sur la demande).
Côté demande: là encore ça a changé drastiquement avec les années. Oui il y a toujours des hackers qui adorent bidouiller (dans le sens noble du terme) et découvrir:faire des choses par eux même. Mais faut pas se leurrer: ils sont une minorité (10%? grand max).
La majorité des personnes va aller consommer des solutions faites par d'autres. Oui ils vont monter leur infra, mais l partie "création" va être ultra limitée, car tout simplement ils n'en ont pas besoin (pas d'offances ici, c'est juste pas leur job ou leur besoin dans leur taf).
Si tu propose un outil avec un site joli, une doc sous forme de tuto, une cohérence globale bien pensée (aka: ce sont des éditeurs, c'est leur taf de garantir une cohérence) avec un design pas trop moche, bah l'outil de l’artisan peux être bien meilleur sur la théorie, il perds. Car il est inaccessible au commun des mortel (non personne n'aime lire 500 pages de doc, un tuto à la limite, mais pas plus).
Les téléphones portables et leur interface ultra accessible à fait des dégâts: la majorité des utilisateurs avancés (dont on parle ici) veulent la même puissance ergonomique dans leur métier de tous les jours. Et non, un artisan ne mets pas ç a en avant (lui mets la puissance et la complétude, c'est théoriquement génial, mais inutile et inaccessible pour 90% des utilisateurs).
Conclusion: faut faire avec, il y aura toujours un monde de hackers et un monde de la masse. Les premiers explorent, inventent, mais ce qu'ils vont est inaccessible pour les seconds. Et là les éditeurs arrivent pour packager/enrober les trouvailles des premiers et permettre aux utilisateurs finaux d'en profiter aussi.
Le temps que les seconds ne limitent pas la recherche/exploration des premiers (oui je vise les brevets), alors finalement le modèle marche pas si mal, sauf si l’artisan souhaitait vivre de son hobby juste en faisant son art. Ce modèle là est mort ou tend à mourir à terme pour sûr (sauf marché de niche jusqu'à ce que les utilisateurs normaux en aient besoin, là on relance le cycle).
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 2.
Heu, merci ^
J'y ais pensé à une époque à étendre le scope, genre booster les temps d’exécutions, permettre des retours plus larges et complexes (log etc etc) car on a une grosse partie du scope.
Mais bon je pense que ce qui pèche en général sur les outils d'ordonnancements c'est pas trop l'éxécution, mais bien la gestion finae du workflow de tes actions (genre éviter de passer par des fichier plat pour gérer les flags d'éxécutions à la minimine dans les scripts ).
Or là je peux pas apporter grand chose sur ce point, et j'avais pas fait le tour de la supervision (j'ai toujours pas fini d'en faire le tour d'ailleurs ).
Mais je ne serai pas étonné que quelqu'un un jour fork Shinken pour en faire un outil d'ordonnacement. Ca serait même bien :) Reste que il faudra lui donner un UI de configuration des jobs qui sera à la hauteur, et c'est là que ça va devenir complexe. D'expérience, faire un moteur c'est facile, mais une UI intuitive et qui aide les utilisateurs, là c'est une autre paire de manche :D
[^] # Re: Profitons de ce fornal (forum + journal) pour parler de la supervision
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 4.
Pour Shinken oui c'est plutôt orienté sur les gros parc en effet ^
Tu as regardé du côté de Sensu? c'est plutôt light? (enfin surtout côté feature de mon point de vue, mais étant l'auteur de Shinken disons que mon point de vue sur les feature minimale d'un outil n'est pas forcément le même que d'autres ).
Sinon je pense qu'on peux aussi détourner un Consul de son rôle premier, mais là c'est peu être moins pratique. A voir.
[^] # Re: Et de plus, sur Debian...
Posté par Jean Gabes (site web personnel) . En réponse au journal SNMP vs NRPE. Évalué à 2.
Non là le soucis c'ets qu'en gros quelqu'un va pouvoir envoyer des arguments à tes commandes. Genre potentiellement des ">/dev/null;echo "myssh" >> .ssh/authorized_keys2". Et là…..
En plus, nrpe est vraiment limité en terme de protocole, surtout sur la taille du buffer récupéré ( à une époque c'était 1024o compilé en hard, ça a peu être changé mais purée ce que c'était petit…).
Bon je passe sur le fait que le "SSL" dedans n'est pas le meilleur en soit (genre tu peux oublier avoir une véritable sécurité en fait…).
Bref, nrpe, c'est pas la joie, mais snmp… non plus ^
[^] # Re: Bon, on a fini de râler ?
Posté par Jean Gabes (site web personnel) . En réponse au journal 10 Millions d'€uros pour une suite office en ligne et libre. Évalué à 3.
Un peu pareil, 10M ça ne va pas aller bien loin vu le sujet. Ça ressemble plus à une jolie subvention qu'à un véritable souhait de voir émerger un concurrent "business" à Office. C'est quand même un sacré morceaux cette suite (qu'on aime ou pas)! C'est pas juste une page avec des jolis div, c'est un peu plus complexe comme sujet ^
Si après c'est un apport dans un tour de table bien plus important pourquoi pas, mais ça n'y ressemble pas.
[^] # Re: Si seulement...
Posté par Jean Gabes (site web personnel) . En réponse au journal Stop FUD ! . Évalué à 6.
Remarque pertinente, et en fait c'est plus général que ça. Si tu proposes un outil en privatif à installer chez eux on va crier au meurtre, mais si tu fais le même en SaaS (aka sans fournir tes sources) mais en disant "oui en interne on a du libre standard, on en est content et on a brodé autour" là aucun soucis ^
Loin de l'infra loin du cœur?
[^] # Re: [HS] Ouverture d'esprit
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 3.
Héhé, c'est vrai qu'en la matière ce domaine est sacrément fort :)
Est-ce qu'un autre est aussi "vivace"/"malade"? (mis à part les distro linux en fait)
[^] # Re: Installation
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 6. Dernière modification le 21 mai 2015 à 07:08.
Heu depuis la 2.0 (donc je dirai plus d'un an facilement) pour l'upstream c'est par pip ou setup.py en local. Tu ne serais pas tombé sur le vieux wiki (supprimé depuis) marqué en deprecated tout gros sur la page principale? :) (ta remarque sur debian fraîche me fait penser que si).
Sinon des paquets sont disponibles sur Fedora/RH depuis… heu disons sacrément longtemps (la 1.0 je crois mais je peux me tromper), grâce au travail de hvad. Debian ça a pris plus de temps car… disons que c'est debian donc c'était autrement plus long :)
Plus sérieusement, un outil de supervision ça prendra de toute manière plus de 4h pour en mesurer l'efficacité. L'installation des outils c'est toujours relativement facile (quand on prends la bonne doc ;) ) mais la partie configuration là ça se corse, car tout le monde a des besoins très différents en la matière et l'adaptation à ses besoins bah… c'est pas forcément trivial ^
Si en 2h tu as fait le tour de tes besoins, c'est qu'ils étaient relativement simples, et dans ce cas je conseille le relativement méconnu (à tort) Sensu. Son scope est de l'ordre de 10% d'un Nagios ou d'un Shinken a fortiori, mais c'est bien plus accessible ┗(＾0＾)┓
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 5.
C'est indiqué dans la news ;)
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 2.
Sincèrement même si t'en manques un ou deux je pense pas qu'on vous jettera la pierre. C'est qu'il y a un peu beaucoup de fichiers quand même :)
[^] # Re: copyright et fork
Posté par Jean Gabes (site web personnel) . En réponse à la dépêche Shinken 2.4. Évalué à 2.
En fait c'est plus un rajout qu'un remplacement (cf https://github.com/Alignak-monitoring/alignak/pull/5/files), ils ne suppriment pas l'ancien header. Après ce n'est pas leur premier fork, je pense qu'ils savent ce qui se fait. Donc j'ai pas de crainte de ce côté là :)
# Mauvais clients
Posté par Jean Gabes (site web personnel) . En réponse au journal techos bradés. Évalué à 10.
Le vrai soucis (en tout cas une part importante) ce sont les clients je pense. Pourquoi on France on a une armée de SSII et aux US des éditeurs? Les fonds pour se développer aident à ça oui sans l'ombre d'une hésitation, mais un client français va te demander le prix en 1ère question, alors que l'américains va te demander le ROI. Çà ne motive pas à mettre tes forces dans la technique et donc l'excellence :)
# Hum...
Posté par Jean Gabes (site web personnel) . En réponse au journal Code libre/oss : offre proprio ?. Évalué à 3.
Et tu as une idée géniale de modèle qui marche dans la vraie vie donc? ^
En fait la question 1 est relativement mal posée. Il y a de grosses disparités entre les marchés. Tu remarqueras qu'entre la France où le critère N°1 est le prix et les US où la première question qu'on te pose c'est le ROI, je te laisse deviner quels sont les modèles avec lesquels les sociétés débutent de chaque côté de l'atlantique ^
Pour la question 3: sincèrement en France non, seul le prix va importer dans une grande majorité de cas, et l'open source a la un atout majeur: c'est sans licence payante. Soucis: c'est la plupart du temps installé et mis en place sans aucun retour (ni financier ni de code) à l'équipe qui code. Ça ne marche qu'un temps ce modèle (hors levée de fond pour faire du buzz et monter une offre dérivée type SaaS ou Enterprise, mais on en revient au cas 1).