Leur matos ou pas ça ne change pas le fait que la partie soft peu être faite par un tiers, surtout que là on parle de trucs complexes avec des compilos et cie.
Sinon le vrai risque c'est côté image: "oh ils ne font pas tout eux même, ils utilisent des outils dépassés, etc etc". Et ça c'est autrement plus important pour eux qu'avoir 3 pull requests par an pour fixer une typo dans leur doc.
J'ai déjà réussi à me perdre dans une ville inconnue (Nuremberg) alors que j'avais 600m à faire, avec un plan en main (un peu grossier, juste les grande avenues, soit 2 en fait).
Par contre gérer les représentation spaciales ne me m'a jamais posé de soucis. Peux être un question d'échelle?
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
Pas que, car tu peux aussi avoir certains qui sont obligés d'utiliser des outils dans leur référentiel d'outil si il y en a un qui a été homologué (il y a plusieurs niveaux à l'intérieur et c'est sacrément galère et surtout cher s'y être mais bon).
Les très vitaux pour la nations sont ainsi obligés sur certains secteurs de ne prendre que dans ce catalogue (pas sur le poste bureautique de la secrétaire, mais côté serveur/infra là c'est carrément plus restrictif).
The operational cost of avoiding split-brains altogether is very high
Je pense qu'ils doivent revoir cette estimation, car leur image en ayant pris un coup (comme gitlab à l'époque), je ne suis pas sûr que gérer pleinement les splitbrains soit si cher que ça au final désormais.
Mais c'est bien ça qui est triste, c'est que ça marche et qu'une fois encore le marketing a bien plus de poids que les faits objectifs.
Là où je pense qu'ils prennent des risques, c'est vraiment sur le fait de devoir mettre toute la stack dans leur propre licence, car dans les faits même ceux qui veulent ça sera infaisable (sauf si tu as tout en MIT/BSD, mais bon tu as bien du LGPL dans le tas, voir du GPL sur des processus à côté).
Donc c'est tellement infaisable que là même le marketing va avoir du mal à cacher le côté totalement faux de l'histoire quand les premiers qui vont "essayer" vont démontrer que c'est infaisable.
Je me doute bien qu'ils ont déjà prévu ça, juste que d'habitude ils mettent déjà les graines de leur future argumentaire dans l'annonce précédente, mais là j'arrive pas à voir l'astuce.
A moins que ce soit un genre de "pied dans la porte": on mets THE grosse limitation dans cette version, ça couine car c'est pas faisable à cause des autres projets GPL qui ne veulent/peuvent pas changer leur licence alors que eux les gentils mongo ils l'ont fait, et donc licence version 2 qui est un peu moins restrictive juste sur ce point là, et hop ils sont les gentils de l'histoire même si on regarde le fil complet c'est totalement l'inverse.
Je ne suis pas totalement d'accord avec cette vision des choses:
En tout cas, cela semble être une belle tentative de la part de MongoDB à faire basculer une bonne partie des utilisateurs vers la version payante du logiciel. […]
En effet, si tu prends le soucis d'un autre angle, ils demandent simplement la même chose que la GPL, mais au niveau du service, un peu comme on prends au niveau du processus pour la GPL.
Donc forcer oui, mais à respecter les règles du logiciel libre sur le long terme, plus que juste open source, car c'est trop simple de bypasser l'AGPL dans les faits.
Est-ce qu'au passage ceci va faire que certains qui ne veulent pas fournir leur code vont devoir payer, oui. Est-ce si mal que ça? (si on se place du côté logiciel libre).
Bon après d'une manière plus réaliste, je pense comme toi qu'en effet c'est un bon effet marketing & juridique => monétisation en hausse de leur offre. Et si c'est vraiment forcer à ouvrir toute la stack d'un service, ça va migrer sérieusement dans le futur, ou bien ne pas mettre à jour.
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 ^
[^] # Re: nvidia
Posté par Jean Gabes (site web personnel) . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 3.
C'est juste, toutes mes excuses pour eux.
[^] # Re: nvidia
Posté par Jean Gabes (site web personnel) . En réponse au journal Le dégonflage des mythes Wayland... dégonflés sur Reddit. Évalué à 8.
Leur matos ou pas ça ne change pas le fait que la partie soft peu être faite par un tiers, surtout que là on parle de trucs complexes avec des compilos et cie.
Sinon le vrai risque c'est côté image: "oh ils ne font pas tout eux même, ils utilisent des outils dépassés, etc etc". Et ça c'est autrement plus important pour eux qu'avoir 3 pull requests par an pour fixer une typo dans leur doc.
# Réponse: non dans mon cas ^^
Posté par Jean Gabes (site web personnel) . En réponse au sondage Les programmeurs ont-ils le sens de l'orientation ?. Évalué à 2.
J'ai déjà réussi à me perdre dans une ville inconnue (Nuremberg) alors que j'avais 600m à faire, avec un plan en main (un peu grossier, juste les grande avenues, soit 2 en fait).
Par contre gérer les représentation spaciales ne me m'a jamais posé de soucis. Peux être un question d'échelle?
[^] # Re: SSPL vs AGPL
Posté par Jean Gabes (site web personnel) . En réponse au lien pas de MongoDB dans Debian et RedHat. Évalué à 0.
Dans ce cas la GPL c'est pareil non? Là où avant le lien c'était un lien dans un processus là c'est un lien dans le réseau. Entre un OS qui est sur ton CPU/RAM et un autre qui est distribué entre X nœuds sur le réseau, bon ça reste dans une même philosophie. (même si un processus GPL ne forçait pas les autres processus on est d'accord, d'où le "plus libre" car il étends l'application forcée des libertés).
Je suis d'accord sur le fait que c'est plus libre que libre.
Mais oui ça va à l'encontre total des habitudes de l'open source d'aujourd'hui (dans le sens base d'outils open source pour sous tenir un service qui lui est commercial) et les consommateurs passifs (au sens production de briques open source eux même) ne vont pas aimer.
Or ils sont la grande majorité donc ça explique tout le bruit (et donc l'image négative) autour du changement de mongo.
# Terme un peu fort ^^
Posté par Jean Gabes (site web personnel) . En réponse au lien Le serveur PEAR est hors-ligne suite à une infection.. Évalué à 2.
"Infection" : le terme est un peu fort je trouve: ce n'est que du PHP. Ok c'est pas génial, mais de là à le traiter d'infection quand même…. (⌐■_■)
Plus sérieusement, pas de chance pour ceux qui l'utilisent dans leur build actuellement.
[^] # Re: ni chaud ni froid
Posté par Jean Gabes (site web personnel) . En réponse au journal KDE is dying. Évalué à 1.
Pas que, car tu peux aussi avoir certains qui sont obligés d'utiliser des outils dans leur référentiel d'outil si il y en a un qui a été homologué (il y a plusieurs niveaux à l'intérieur et c'est sacrément galère et surtout cher s'y être mais bon).
Les très vitaux pour la nations sont ainsi obligés sur certains secteurs de ne prendre que dans ce catalogue (pas sur le poste bureautique de la secrétaire, mais côté serveur/infra là c'est carrément plus restrictif).
[^] # Re: Faut lire les journaux
Posté par Jean Gabes (site web personnel) . En réponse au journal Github m. Évalué à 2.
Faut croire que leur mécanisme de splitbrain a mal fonctionné (cf https://githubengineering.com/mysql-high-availability-at-github/ où ils en parlent):
Je pense qu'ils doivent revoir cette estimation, car leur image en ayant pris un coup (comme gitlab à l'époque), je ne suis pas sûr que gérer pleinement les splitbrains soit si cher que ça au final désormais.
[^] # Re: Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . En réponse au journal SSPL: All your service are belong to us. Évalué à 5.
Mais c'est bien ça qui est triste, c'est que ça marche et qu'une fois encore le marketing a bien plus de poids que les faits objectifs.
Là où je pense qu'ils prennent des risques, c'est vraiment sur le fait de devoir mettre toute la stack dans leur propre licence, car dans les faits même ceux qui veulent ça sera infaisable (sauf si tu as tout en MIT/BSD, mais bon tu as bien du LGPL dans le tas, voir du GPL sur des processus à côté).
Donc c'est tellement infaisable que là même le marketing va avoir du mal à cacher le côté totalement faux de l'histoire quand les premiers qui vont "essayer" vont démontrer que c'est infaisable.
Je me doute bien qu'ils ont déjà prévu ça, juste que d'habitude ils mettent déjà les graines de leur future argumentaire dans l'annonce précédente, mais là j'arrive pas à voir l'astuce.
A moins que ce soit un genre de "pied dans la porte": on mets THE grosse limitation dans cette version, ça couine car c'est pas faisable à cause des autres projets GPL qui ne veulent/peuvent pas changer leur licence alors que eux les gentils mongo ils l'ont fait, et donc licence version 2 qui est un peu moins restrictive juste sur ce point là, et hop ils sont les gentils de l'histoire même si on regarde le fil complet c'est totalement l'inverse.
On verra bien, si c'est ça ca va vite arriver.
# Forcer la main, ou juste respecter les (anciennes) règles?
Posté par Jean Gabes (site web personnel) . En réponse au journal SSPL: All your service are belong to us. Évalué à 4.
Je ne suis pas totalement d'accord avec cette vision des choses:
En effet, si tu prends le soucis d'un autre angle, ils demandent simplement la même chose que la GPL, mais au niveau du service, un peu comme on prends au niveau du processus pour la GPL.
Donc forcer oui, mais à respecter les règles du logiciel libre sur le long terme, plus que juste open source, car c'est trop simple de bypasser l'AGPL dans les faits.
Est-ce qu'au passage ceci va faire que certains qui ne veulent pas fournir leur code vont devoir payer, oui. Est-ce si mal que ça? (si on se place du côté logiciel libre).
Bon après d'une manière plus réaliste, je pense comme toi qu'en effet c'est un bon effet marketing & juridique => monétisation en hausse de leur offre. Et si c'est vraiment forcer à ouvrir toute la stack d'un service, ça va migrer sérieusement dans le futur, ou bien ne pas mettre à jour.
[^] # 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 ^