Jean Gabes a écrit 458 commentaires

Ça les fait réélire de penser sur le fond des choses? J'en doute, ça ne peux se résumer en une petite phrase qui choque reprise partout et qui fera parler de lui (la preuve ici).

Le mieux serait que les journaux/relayeurs tentent de décortiquer ce qu'il fait et non pas partir ce ce qu'il dit: il prends un arguments et l'étends à l'infini pour le rendre débile. Je ne me souviens plus du nom exact de la méthode, mais ça n'a rien à voir avec la recherche de la vérité ça c'est sûr ^{^}

Et on ne devrait parler que de ça, jusqu'à ce son message soit tellement NON relayé à sa base électorale qu'il doive alors parler sur le fond (les pour et contre de la 5G par exemple?).

Bref, c'est pas demain la veille :(

Sincèrement je pense que ça fait un moment qu'on l'a quitté. Les systèmes d'aujourd'hui sont autrement plus complexes qu'avant, et je ne parle même pas des architectures serveur/haute disponibilité et déploiement.

D'un côté tu as une industrie qui est de plus en plus.. bah une industrie, donc exit les artisans.
Et de l’autre une majorité d'utilisateur a dans sa poche un appareil avec une ergonomie de fou, et souhaite retrouver cette ergonomie partout, donc au travail également (couleur, caractères utf8 pour facilité l'affichage des blocs, etc).

Bref, le nombre de ligne de code ne va faire qu'augmenter je pense ^{^}

Je pense qu'il dit qu'on va finir comme les US avec une culture scientifique très basse dans la population, et le moindre gourou pourra balancer des contre vérités sans que ça ne se remarque et ainsi faire des dégâts monstrueux pour son seul intérêt.

J'avoue que c'est très clairement dit, alors que le sujet était sacrément tendu/tordu. Félicitation.

Maintenant place aux trolls malheureusement qui ne vont pas manquer avec un tel sujet :(

Ah c'est tout à fait juste, je n'y avais pas pensé en terme de volume. Là des valeurs en nombres absolus seraient plus utiles.

Oui c'est tout à fait vrai, mais cette perception (car ce n'est juste que ça) va beaucoup influer sur le choix du langage des nouveaux projets. Que tu ais une niche qui fasse toujours des anciens langages est normal (un langage ne disparaît pas), mais sans un minimum d'activité, il n'a plus aucun intérêt pour le monde extérieur à cette niche.
Mais c'est pas forcément "mal", la niche sera très contente avec son outil, et le reste se fichera bien de ce qui se passe dedans.

C'est très pratique et bien fait, mais je crains que ce PI4 ne fasse pas aussi bien que ses prédécesseurs à cause de ce problème de surchauffe. Le côté refroidissement passif de ces petites bêtes était quand même un argument majeur pour beaucoup.

Ca passe si tu veux en faire un boitier multimédia, mais bon pour le reste c'est pas l'idéal.

Contrairement à certains qui semblent se dire "nul/inutile=>ça existe déjà via X" (X=gros outil qui fait tout, et surtout en plus vu qu'ils mis du temps à le digérer donc ils aimeraient bien le replacer partout et que ce soit la norme), je pense que ce projet a un intérêt.
Car, et c'est uniquement une perception personnelle sans chiffres à la clé, faire "juste ce qu'il faut" est bien une qualité qui se perds de plus en plus dans les projets open source, en tout cas ceux mis en avant.

En même temps, si les grands projets sont mis en avant c'est qu'il y a du marketing (point de magie), donc des fonds (et beaucoup), donc il faut que ça touche une masse importante d'utilisateurs qui peuvent payer à terme (un produit ou service dérivé), donc ça touche surtout les gros environnements (les petits ne paient pas).
D'où l'importance de ce genre de projet qui mettent l'accent sur la facilité d'accès, et dont les limites sont justement une grande force je trouve.

Bravo donc :)

Pour le coup il est un peu facile d'attaquer Amazon même s'ils abusent de leur position.

Mon avis est qu'Amazon n'est pas le principal coupable dans l'histoire, mais plutôt la communauté dans son ensemble ces 15 dernières années sur le fait qu'elle n'a pas été capable de produire un modèle économique viable (je doute que RedHat soit un modèle viable, sinon on en aurait une armée d'autres depuis le temps).

Le fait même que l'on ait Libre = gratuit = aucun besoin de réciprocité ça a tué la plupart des modèles économiques viables ("la communauté/les autres fera/feront le support, aucun intérêt pour que moi je paie").

Après on peux dire que l'on va faire sans modèle économique, et qu'on va faire avec pleins de petits projets (les gros il faut bien les financer d'une manière ou d'une autre, or là le seul moyen à portée c'est bien de faire du non open source).
Mais on aura des projets à deux vitesses avec d'un côté les projets lancés par les gros opérateurs afin que les personnes migrent leur usage sur leurs instances en SaaS/*aaS et de l'autre des projets bien plus modestes qui n'attendront jamais la masse marketing suffisante pour être visible face aux premiers (sauf niche bien particulières où les premiers ne sont pas).

En fait on en revient au modèle du début des années 2000 avec juste comme différences que les gros acteurs sous licence sont désormais de gros acteurs avec un moteur en open source, et les petits acteurs ne pouvant pas grand chose face aux premiers et n'ayant aucune manière crédible de prendre un part de marché aux premiers.

On a déjà accès aux moteurs, c'est déjà ça, finalement on y a gagné :)

Non, la paire ici est un tuple, que tu ne peux pas modifier. Tu dois en recréer un et le réassigner dans le dict.

C'est tout à fait juste, et d'un point de vue utilisateur on va y gagner sur le court terme, mais d'un point de vue économique il va y avoir un problème dans le financement de futur projets. Qui va encore financer le bootstrap de gros projets comme ça sans espoir d'éviter que le mastodonte Amazon ne vienne lui manger son business?

Or il ne faut pas se leurrer, on a mongo, elastic ou docker à ce niveau de finition car ils ont eu des financements qui ont permis de payer les dev et surtout le marketing qui après à permis à la communauté de se focaliser sur ces projets et les améliorer/industrialiser ensuite. Ce n'est plus l'inverse comme avant où c'était les communauté qui créait des champions qui après pouvaient se financer.

Bon si ce sont surtout les gros acteur du SaaS qui développent des moteurs en open source why not, mais alors in-fine 90% de l'utilisation qu'on aura sera sur ces plates formes, donc bah… non open source ^{^}

On ne peux pas leur demander de fournir directement des $ aux auteurs alors qu'ils fournissent déjà du code. Pour moi c'est l'un ou l'autre, mais demander les deux ce n'est pas très correct pour eux.

Ensuite c'est plus que là le modèle économique de coo-pétition arrive à ses limites. Le développement et surtout l'organisation et le marketing nécessaire pour faire connaitre son produit est juste faramineux désormais avec la concentration des utilisations vers quelques outils au lieu d'une large diversité avant.
Mais l'essentiel des flux économiques n'arrivent pas vers les auteurs car désormais les utilisateurs préfèrent payer pour le service tout compris que mettre en place et gérer eux même (on ne peux pas leur reprocher).

Ici AWS et Elastic sont en compétition frontale, avec AWS qui récupère les plus values et Elastic qui a principalement investi (et là on parle en M$), donc forcément ça coince et ça se tire dans les pattes.

On risque donc d'arriver à une situation où on aura:
* un retour des outils sous licence pour une utilisation en interne, basé sur des moteurs open source, mais avec une scalabilité limitée (mais bien souvent suffisante)
* un service SaaS/PaaS avec les sources des moteurs des services qu'on utilisera, mais bien sûr pas le code et surtout la configuration et l'expertise pour le mettre en place à grande échelle (c'est leur métier à Amazon, et on ne donne pas gratuitement son métier)

Dans tous les cas on aura de bon moteurs, c'est déjà ça ^{^}

Amazon tente de dire que non ce n'est pas un fork, avec autant de rajout et une opposition frontale au business d'elastic, c'est un vrai fork.

Que certaines modifications soient reportées upstream le temps que ce dernier est encore en vie oui, mais par exemple les parties sécurité qui font doublons avec la version Enterprise d'Elastic elles ne seront jamais intégrées upstream en open source.

Je pense qu'on va avoir une pénurie d'investisseurs pendant quelques temps pour lancer de nouveau gros outils comme ça avant que la parade à AWS ne soit trouvée. Car là certains vont perdre beaucoup d'argent, et ça ne sera pas Amazon ^{^}

Et quand il y a une diminution du revenu de la société? On applique la même relation?

Tu vas me dire que dans un certain sens c'est déjà le cas, avec certains qui sont mis dehors, les autres gardant le même salaire.

Je vous d'ici l'échange, digne des face à face entre bandes rivales sur un pont, de nuit, chacun avec son otage :)

On les disait mort sur l'année 2018, on est en 2019 et on ressort la même chose.

C'est vrai qu'ils se sont fait prendre de vitesse sur la monétisation de tout ça. Les ordonnanceurs et autres surchouches K8s sont ce qui est utilisé par les plus grands comptes et que la partie principale de leur ancien dev n'est que le moteur d'un outil tier, donc non monétisable (ou juste à la marge, mais ça ne fera clairement pas le chiffre voulu par les investisseurs).

Mais faut pas tout jeter non plus. Il faut voir si leur version Enterprise n'attaque pas plus sérieusement les grands comptes qu'un écosystème comme k8s ne saurait le faire. La présence de vrai outil d'audit et de rapport pdf de consommation peux avoir bien plus de valeur au yeux de ceux qui sont près à payer pour un tel outil qu'une meilleure intégration pour automatiser le déploiement d'un loadbalanceur.

Si par contre ils tentent de jouer les muscles sur la partie technique face à Kubernetes là c'est sûr, c'est trop tard.

C'est juste, toutes mes excuses pour eux.

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.

"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.

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

Faut croire que leur mécanisme de splitbrain a mal fonctionné (cf https://githubengineering.com/mysql-high-availability-at-github/ où ils en parlent):

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.

On verra bien, si c'est ça ca va vite arriver.

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.