Graalvm c'est tres bien pour les outils en ligne de commande ou la reactivite est importante. Mais ca m'interesse moins cote serveur ou je prefere beneficier du potentiel complet de la JVM et de ses optimisations.
Les attaques personelles et la mise en champ d'un debat simpliste et bebete en mode "moi gentil contre les mechants de pas-mon-parti" deraillent tout le propos du journal, ce qui est dommage.
Il faut préciser que les deux protagonnistes n'ont aucune légitimité pour parler d'environnement.
Ils n'ont jamais milité dans des associations écologistes et n'ont pas de formation en rapport avec l'écologie.
Toutes les personnes qui ont des choses interessantes a dire sur le sujet sont legitimes.
Rejetter les propos de gens qui ne font pas parti des associations que tu approuves n'aurait pour effet que de creer une chambre a echo et rater d'autres points de vue tout aussi importants et interessants.
Vous noterez dans la conf que Clever Cloud (l'entreprise de Quentin Adam) cherche à minimiser l'électricité utilisée dans ses datacenters, c'est évident puisqu'il ne fait pas payer l'électricité, il fait payer la ram et le cpu.
Donc en fait, quand tu achetes ton pain a la boulangerie, tu ne paies pas l'electricite? Quand tu achetes un logiciel, tu ne payes pas le salaire des developpers ou de la receptioniste?
Une entreprise a des couts et des revenus. Les couts inclus les salaires, impots, eau, electricite, et meme les repas si ils les servent. De facon a pouvoir pereniser l'entreprise, ces couts sont captures dans les prix de vente et ce que vont payer les clients.
Donc un fournisseur de cloud fera definitivement payer l'electricite utilisee (et les generateurs, et les employes…) dans les datacenters a ses clients.
Je n'ai aucune idee pour clever cloud ou gandi, mais il y a un certain nombre de datacenters et fournisseur de cloud qui sont carbon neutral. Preuve etant qu'il n'y a pas que les membres de ton association d'ecolo qui s'interessent a l'ecologie et le rechauffement climatique.
Pendant de longues minutes, ils expliquent que peu importe qu'on supprime nos mails, la taille du disque dur ne change pas. C'est vrai la taille des disques dur ne changent pas.
mais si 500 000 personnes suppriment 1Go de mail, on économise 500To au global, et donc on peut diminuer l'infrastructure d'autant et donc supprimer des dizaines
de disques (avec les sauvegardes, avec des temps d'indexation et de recherches plus court et tout ce qu'il faut pour que ces disques fonctionnent). Est-ce que c'est beaucoup ? Non c'est très peu en rapport de la taille totale de gmail. Mais ce n'est pas rien, question de point de vue. C'est très peu de CO2 évité de trier ses déchets aussi mais ce n'est pas une raison pour ne pas le faire.
Il n'y a pas de petites economies en effet.
Mais le probleme souleve dans la video est que c'est un point systematiquement trop mis en avant de facon alarmiste. Et tant qu'a mettre quelque chose en avant, autant mettre quelque chose avec bien plus d'impact.
Certains pensent que la France ne représente que 1% des émissions de CO² donc il faut que les autres commencent à agir d'abord, ce même argument revient plusieurs fois un peu différemment, ce n'est pas la France le pire, c'est pas l'informatique le pire etc.
Il faudrait arreter de s'imaginer des ennemis et ecouter un peu plus ce qu'ils disent dans la video.
Il y avait notamment un point interessant qui disait grosso modo que vu l'impact disproportione des transports et de l'energie, il serait benefique de numeriser pas mal de services de facon a ce que les gens n'aient pas a se deplacer et ainsi reduire leur impact sur l'environnement.
Bref, beaucoup de blabla dans le but de garder le business as usual. Parce que admettons que l'informatique en générale ne soit pas dans les
diminutions à réaliser en priorité, est-ce que les speakers ont arrêté de prendre l'avion et de manger de la viande ? Les photos à New-York et les
tweets sur la raclette montrent que non. On est bien face à des personnes qui ne veulent rien changer dans leur mode de vie et incitent les autres à faire pareil.
Ca sent surtout le virtue signaling.
Ou alors ils veulent nous faire croire que ce sont les écologistes les idiots dans le but de garder le business as usual.
Pourquoi s'inventer ces presentateurs en ennemis?
On a la chance d'avoir eu deux personnes qui sont impliques dans le cloud francais s'interesser au sujet, faire de la recherche et de la preparation dessus, proposer leur presentation a la conference et y aller. Au lieu de s'imagine en victime persecute, il serait bien plus interessant d'elever le debat et de se concentrer sur des points tangibles et qui pourraient avoir in impact positif.
Elasticsearch est super basique sur AWS. Il y a pas mal de limitations et ne rend pas la vie facile.
Du point de vu experience utilisateur, la version d'Elastic est a des annees lumiere. Ils ont aussi des opportunites qu'AWS ne pourra jamais explorer (ex: cross-cloud).
Je trouve qu'au contraire cela a beaucoup a voir avec la morale. Elastic avait un melange de code libre et non-libre au sein du meme depot. Ils n'encouragent pas non plus une communaute de developpeurs. En fait, ils ont une position qui n'est pas egale aux autres contributeurs.
Ils veulent surtout le benefice du libre sans les inconvenients de facon a ce que leur produit soit facile a introduire et essayer, mais que l'on soit force de leur payer si on veut utiliser cela en production.
Je comprends l'appetit economique d'Elastic et leur attitude anti-competitive, mais en tant qu'utilisateur de logiciel libre, cela me force a considerer d'autres alternatives libres telles qu'Apache Solr.
N'etant qu'un etranger d'Internet, il est difficile de donner des conseils avec precisions.
Ceci dit, si le probleme n'est pas avec le boulot, changer non seulement de boulot mais aussi de domaine rajoute un gros risque.
Avec ta position actuelle, tu es deja familier avec les differents acteurs, les responsabilites, tu sais quoi faire en cas d'urgence. Avec un nouveau domaine, tout sera a re-apprendre et risque de generer encore plus de stress.
Donc avant de completement changer de boulot, mon conseille serait d'evaluer quels sont les risques que tu mentionnes et comment simplifier ta vie afin de te donner plus d'espace pour que tu puisses addresser tes problemes:
Si tu te sens frustre par le fait de te prendre les consequences d'actions d'autres personnes, parles en avec ton manager. Il doit y avoir des considerations que soit toi, soit ces personnes n'avaient eu vent
Deplace ton energie creative ailleurs. Sur quelque chose que tu controles completement (ex: projet perso ou autre)
Simplifies ta vie privee. Si cela signifie que tu dois te faire delivrer des plats prepares ou aller au restaurant, fais le.
Simplifies les taches menageres.
Tu n'as pas pris de vacances. Prends en, meme si c'est pour rester a la maison.
Prepares les choses en avance afin de ne pas avoir a reflechir et simplifier les choses. Fais meme un calendrier pour ca.
Tout a fait! Et c'est l'un des gros avantages de l'ASF!
Ceci dit l'ASF n'est pas completement immunise contre ce genre de tactiques. Voir par exemple tous les coups bas entre les differentes boites liees au big data et comment ils ont fait le forcing pour enlever la clause de diversite pour la graduation de l'incubateur.
Next week we’ll be cutting the first release candidate for the 0.11.0 release. While this release includes significant improvements in the query engine and the clustering code base, it will be the last open source version that includes clustering. In April, we’ll release 0.12.0, which will be fully open source and have great new features, but it will be focused on the standalone InfluxDB server. Both of these will be drop in replacements for the current stable 0.10.3 release.
For our users looking for free open source options, we’ll be releasing the open source InfluxDB Relay project along with a landing page how to achieve high availability using pure open source and subscription options with the 0.12.0 releases and beyond. From that point forward our clustering efforts will be focused on the closed source Influx Enterprise offering.
Dans les projets libres que je recommande, je ne regarde pas juste la license du logiciel mais aussi si il y a une communaute autour. Un logiciel libre pousse par une boite sans communaute se rapproche plus d'un shareware que d'un logiciel dans l'esprit du libre. Et note que c'est voulu et admis (de facon semi-ouverte) par la plupart de ces boites.
Et pour rappel, voici ce qu'a dit le CEO de mongodb recemment:
[W]e didn't open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.
La plupart de ces boites veulent beneficier de l'aura positive des logiciel libres sans pour autant s'y investir completement. Realistiquement, ells vont mettre des barrieres a la contribution tiers.
En tant qu'utilisateur, je veux m'assurer les que les interets des utilisateurs passe en premier pour eviter que d'autres ennuis comme le clustering d'influxdb ne m'arrive. Je veux aussi pouvoir contribuer de facon positive au projet si necessaire et meme beneficier du choix de plusieurs fournisseurs de services si necessaire. Et c'est bien pour ca aussi que le motto non-officiel de l'ASF est "community over code".
Si on prend le cas d'elasticsearch, cela reste tres problematique combien meme le coeur est libre:
Ils ont tout mis dans le meme depot git, que ce soit la partie libre ou la partie pas libre. Du coup ce qui se passe dedans n'est pas forcement clair (ex: si je construit un tar, comment ca se passe?) mais cela rend plus complique toute contribution (ex: j'ai du code a contribute mais ca risque de casser une de leur partie proprio or entre en concurrent).
De meme il n'y a pas vraiment de communaute de developpeurs pour elasticsearch, seulement des utilisateurs. Note: Avoir une visibilite dans les tickets et pr du repository ne compte pas vraiment comme communaute.
Chronograf est un autre product open core, que je ne compterai pas dans la categorie libre. Pour rappel, les gars d'influxdata, qui sont derriere chronograf, sont les memes qui ont enleve tout code lie au clustering d'influxdb pour le rendre proprietaire et rabaisser le coeur libre.
Elasticsearch n'est que l'enrobage de la bibliotheque Apache Lucene dans un service distribute. Donc on peut arriver a la meme chose avec Apache Solr qu'Elasticsearch. L'avantage d'elasticsearch est qu'il a ete longtemps l'outil le plus facile a deployer et a integrer avec des connecteurs pour tout ce qui est a la mode et le fait que l'on pouvait envoyer des documents sans avoir a definir de schema au prealable. Apache Solr Cloud s'est pas mal ameliore en terme de facilite d'utilisation depuis.
D'ailleurs pour tous mes prochain projets, je vais regarder en premier Apache Solr.
Le Mossieur a quand meme une bonne remarque sur ce point.
Ce journal et les commentaires defendant mobiscoop mettent beaucoup en avant le fait que ce soit libre, que cela tente de minimiser les couts et avoir un systeme plus humain. Le tout s'opposant a blablacar en evoquant l'argent et autres symboles associes.
Le fait que le code ne soit qu'open core et que ce soit proprietaire en dual license n'est pas du tout en accord avec les valeurs affichees abondamment par mobiscoop.
Si mobiscoop veut etablir un systeme en accord avec ses valeurs affichees, faire du proprietaire y va a l'encontre. Permettre aux gens d'avoir et heberger leur propre version ne peut qu'aller dans le sens de ces valeurs (ex: avoir une instance a l'echelle d'une boite pour aider et encourager les employes a faire du covoiturage). Le proprietaire n'a de sense que dans un contexte ou on essaie de rendre les utilisateurs captifs afin de maximiser le profit.
D'un point de vu potentiel contributeur, cette situation actuelle me fait fuir et eviter de toucher au code a ce projet car du point de vu license c'est le bordel:
* Il y a un badge de license AGPLv3. Cool, ca a l'air d'etre libre
* Je regarde la license https://gitlab.com/mobicoop/mobicoop/blob/dev/LICENSE et ca a l'air d'etre la license standard pour l'AGPLv3.
* La license specifiee dans https://gitlab.com/mobicoop/mobicoop/blob/dev/package.json#L42 indique aussi GPLv3. Donc pour le moment, pas de proprio
* Je vais sur leur doc referencee sur leur README.md ( https://mobicoop.gitlab.io/mobicoop/#/ ) et voir tout en bas:
Mobicoop software is owned by Mobicoop cooperative. Mobicoop cooperative is opened to any individual, company or public authority who >wish to become a shareholder.
In order to increase the impact of our platform to any sort of clients whatever type of contractual relationship they require, Mobicoop software >is dual-licensed:
- AGPL-3
- proprietary software
Since Mobicoop is dual licensed AGPLv3/proprietary, all components used for Mobicoop must be compatible with both licenses. As a consequence, all components integrated into Mobicoop source code must be released with a permissive open source license. More information on license compatibility for software components and content components (Creative Commons issues).
Mobicoop CI process includes a License Management which checks the license of all components part of a merge request. The most common permissive licenses have already been added to the approved licenses list of this License Management process.
In case you have one of the following situation while merging, please get in touch with Mobicoop project licensing issues expert before merging:
- one of the license pops up as non part of the approved license for the project
- a component is license under AGPLv3 and is not Mobicoop itself
Donc ce n'est pas AGPLv3 en fait? Ou se trouve cette autre license proprietaire?
Les licenses dans les sous repertoires semblent toujours etre l'AGPLv3 standard
La license dans les en-tetes, quand elle est specifiee, est contradictoire. On y trouve:
/**
* Copyright (c) 2018, MOBICOOP. All rights reserved.
* This project is dual licensed under AGPL and proprietary licence.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
*
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
*
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see .
***************************
Licence MOBICOOP described in the file
LICENSE
**************************/
Donc ca dit que c'est AGPLv3 ET proprietaire. Mais la encore cette license proprietaire n'est definie nul part. De meme je n'ai vu nul part de Contributor License Agreement (CLA ou son equivalent francais). J'ai aussi regarde quelques merge requests au cas il y a une verification du fait que chaque contributeur donne une license perpetuelle proprietaire a la boite derriere mobicoop, mais je n'ai rien trouve de tel.
Donc au final, je leur souhaite de reussir mais aussi:
* Je serais curieux de comprendre la difference de raisonnement pour le cote proprietaire du code. Je n'ai pas trouve d'explication sur le site
* Je leur conseille de se renseigner plus sur les licenses proprietaires vu qu'en l'etat cela ne me semble pas applicable. Voir a titre d'exemple https://www.elastic.co/contributor-agreement ou https://www.ubuntu.com/legal/contributors ou encore https://www.clahub.com/ . Ceci dit je suis loin d'etre un avocat et tres loin d'etre fan des projets libres qui me demandent le droit d'utiliser mes contributions pour leurs produits proprietaires.
Posté par Paf .
En réponse au lien Elastic Search préforké.
Évalué à 3.
Dernière modification le 14 mars 2019 à 09:36.
Il faut tout d'abord separer les differents problemes.
En premier lieu, je ne pense pas que ce soit un bon echange de sacrifier sa liberte pour du code. Si moi ou AWS ne peuvent fournir un service d'hebergement d'elasticsearch, ce n'est pas libre. Donc je ne vois rien de mal a avoir AWS ou autre fournir un tel service d'hebergement.
Ce serait aussi injuste vis a vis des autres projets qui sont au coeur d'Elasticsearch comme netty ou apache lucene. Elastic devrait les remunerer.
Tout ca me rappelle d'ailleurs ce qu'ecrivait RMS il y a presque 30ans: https://www.albertopettarin.it/fsfs2/fsfs2.xhtml#x1-590006
Par ailleurs, AWS l'a demontre avec mongodb: si ca vaut le coup, ils developperont une facade pour supporter le protocole de mongodb sans utiliser une seule ligne de code de mongodb. Donc ca ne protege en rien elastic.
Donc que peut faire Elastic? Ils peuvent se congratuler! Ils sont devenus si populaire et gros qu'AWS leur paie attention. Ensuite ils peuvent accepter qu'Elasticsearch est devenue une commodite. Se fermer et se replier serait une erreur car la communaute l'abandonnerait au profit du fork le plus accueillant (ou Apache Solr) et ne ferait que renforcer sa competition. A la place:
S'ouvrir plus et accepter qu'Elasticsearch est une commodite. Mine de rien Elastic a le plus de contributeurs sur le projet, ce qui lui donne le plus d'influence. Ils baissent la barre pour contibuer a Elasticsearch et ainsi rendre le developpement trop gros/rapide pour un fork.
Redoubler d'efforts sur l'hebergement. Il y a plusieurs opportunites qu'AWS ne pourra jamais supporter comme cross-cloud federation. Ils peuvent aussi s'etendre horizontalement (comme une plateforme) ou verticalement (plutot cote applicatif comme ils ont tente avec un APM). Faciliter son integration avec les domaines en poupes comme le deep learning (ex: tres utile pour chercher a base de vecteur) ou IoT. S'assurer aussi d'une bonne integration avec les bibliotheques et cadres populaires (spring, react, ruby, etc.)
Monter au prochain niveau d'abstraction avec une strategie open core. Etablir une separation claire et nette entre la commodite (elasticsearch) et la partie proprietaire qui sera au dessus. Ca permet de non seulement garder la communaute, mais de l'etendre tout en beneficiant de ses avancees
Reduire le pouvoir d'AWS avec un investissement dans les technologies cloud agnostic. Genre s'assurer une bonne integration avec Kubernetes
Quant au financenent en general, c'est assez vague. Mais si elasticsearch n'existait pas, tout le monde utiliserait Apache Solr :)
La difference de popularite s'explique surtout a la facilite d'utilisation d'elasticsearch a mon avis.
Un gros facteur ici est le fait qu'Elastic a recu pas mal d'investissements, ce qui rajoute pas mal de pression pour des retours.
Un autre example serait aussi de regarder et s'inspirer d'autres gros projets qui ont beaucoup de succes et ont du developpement finance par plusieurs entreprises:
Il y avait la meme question lorsqu'Oracle voulait donner OpenOffice a la fondation Apache. Il existait deja LibreOffice et la reputation d'Oracle n'etait pas franchement bonne. Donc c'etait quoi l'interet de jouer le jeu et de l'accepter?
La position de l'ASF est que ce n'est pas un investisseur ou ne specule pas sur les projets. Ils ne font que fournir un cocon pour aider les projets a se gerer. Donc ils ne vont pas juger en se basant sur les chances de success.
L'interet est que l'on se retrouve avec le choix:
l'ASF refuse et ne fait rien -> Le code source n'est jamais libere et disparait
l'ASF accepte mais il n'y pas vraiment de communaute qui se forme -> On archive le projet mais l'ASF a toujours les droits et le code est toujours dispo sous license libre. Voir https://attic.apache.org/ pour les projets archives
l'ASF accepte et une communaute se construit autour du projet -> Tout va bien, on a un projet vibrant et libre
Et du point de vus succes, la fondation Apache n'a rien d'une poubelle. Rien que le poids financier des projets genre Apache Hadoop/hbase/spark/mesos/flink/lucene/solr/camel se compte en millards de dollars. Ou je pourrais aussi mentioner l'impacte que d'autres projets ont sur l'ecosysteme entier comme Apache Httpd, Maven, ivy, commons, groovy
Posté par Paf .
En réponse au lien Elastic Search préforké.
Évalué à 3.
Dernière modification le 12 mars 2019 à 23:46.
Je pense que cette situation est le resultat d'une communaute qui n'est pas saine et ne remet pas en cause le financement de projets libres.
D'autant plus qu'Elastic a aussi un service d'hebergement pour Elasticsearch qui se porte plutot bien.
Le probleme ici est que Elastic a un controle total sur le projet et qu'ils ont commence a en profiter pour leur avantage, au detriment du projet lui-meme et de sa communaute.
Ce n'est pas la premiere fois et ce ne sera pas la derniere fois non plus. Voir entre autre:
Oracle et OpenOffice
Oracle et Hudson
Oracle et Java
InfluxDB et les fonctionnalites qu'ils ont enleve dans le code libre pour le garder seulement dans leur version proprietaire
Parfois ca passe, parfois ca fork ou parfois le projet se meurt.
En general cela repose sur le fait que la partie libre n'est qu'une version shareware deguisee. C'est tres bien pour experimenter et meme avoir des contributions externes (avec attribution a la boite derriere le projet bien entendu, au cas ou ils veulent changer la license…), mais il faut soit passer a la caisse quand on veut passer en production ou avoir la capacite technique de le faire soi-meme (et qui a un certain cout).
Si l'on rajoute a ca le fait que tout ce qui irait a l'encontre de la boite derriere le projet serait rejete ou rendu impossible, la situation actuelle n'est pas vraiment ideale pour un ecosysteme libre et sain.
Donc le fait qu'AWS pousse vers une remise a niveau n'est pas un mal en soit. C'est une opportunite de rendre le projet plus libre. J'imagine qu'a ce niveau, soit Elastic reste tetu est essaye de resister, soit ils coupent l'herbe sous le pied d'AWS et donnent le projet a l'ASF ou il deviendra plus neutre.
Faire rentrer le projet a l'ASF serait vraiment bien. Il ne peut pas y avoir de co-opetition si les acteurs ne sont pas au meme niveau et c'est exactement ce que fournit la fondation Apache. D'ailleurs on entend souvent "community over code" pour souligner le fait qu'avoir une communaute saine est beaucoup plus important que le code.
Et meme si ce n'est pas parfait, ils ont fait un bon boulot. On peut voir plusieurs entreprises supportant Apache Hadoop, plusieurs entreprises derriere Apache Lucene et Solr et se portent toutes tres bien.
Donc non, le fait que le createur d'Elasticsearch bosse a Elastic ne donne pas le droit a Elastic d'etablir une rente a vie sur du logiciel libre.
Sur le fond, honnêtement, je ne comprends pas pourquoi les grosses boîtes ont un besoin essentiel de faire traverser l'Atlantique aux données personnelles des citoyens européens. C'est quand même une bulle ce truc, tout le monde semble être prêt à payer des bases de données personnelles à des sommes faramineuses, mais sur le fond, est-ce qu'une seule boîte a jamais réussi à faire une quelconque marge dessus?
Les donnees des utilisateurs ne traversent pas l'atlantique dans le but unique de pouvoir revendre les donnees. Il y a aussi l'aspect pratique et technique.
Ne pas avoir a se soucier du pays d'origine des utilisateurs (Internet sans frontieres!) permet d'eviter tout un tas de problemes techniques tels que:
Federation (ou solution similaire) des comptes et services.
Gestion de l'exploitation/infrastructure plus lourde et compliquee
Deploiements plus compliques
BI/Data analysis plus compliques vu qu'il y a maintenant differents points de collection avec differentes politiques de traitement
Rassembler toutes les donnees sous une forme acceptable pour qu'elles puissent etre envoyees aux utilisateurs qui les demandent et offrir la possibilite de les rectifier.
Donc a moins que ne ce ne soit un besoin fortement exprime par les utilisateurs ou une contrainte imposee par la loi, les boites n'ont pas vraiment de raison de separer les donnees par continent/pays.
Je recommande quand même la même chose d'un point de vu général pour faciliter les contributions. Et aussi d'avoir un readme à la racine de ton dépôt avec un lien vers le site et les instructions de construction.
Du point de vu légal je n'ai rien a rajouter. Il faudrait lister et voir toutes les licences de tes dépendances.
Ce que je recommenderai:
* regarde du côté de https://www.playframework.com/documentation/2.5.x/Deploying pour construire une archive de déploiement avec les dépendances.
* automatiser le build et les tests. Il y a travis ou circle ci qui fournissent des services de construction gratuits pour les projets libre. Sinon gitlab fournit des cela aussi. Cela à plusieurs avantages, notamment l'assurance de savoir que ton projet puisse être construit pars des contributeurs et de savoir quand un commit casse la construction ou des tests.
Après pour aller plus loin, voir :
* scripts de déploiements pour les différents services. Par exemple ansible ou puppet
* images docker et/ou intégration avec kubernetes. Mais pas tout le monde utilisé pas encore.
La différence se trouve principalement que l’intérêt d'une boite n'est pas nécessairement le même que celui de la communauté et qu'elle a aussi un poids surdimensionne dans les décisions.
Même si GNOME ou systemd ont pris des décisions que l'on apprécie pas, elles ont toutes ou presque été faites a la suite de discussions et/ou votes (ex: https://lists.debian.org/debian-ctte/2014/02/msg00294.html ). Par ailleurs les décisions ont ete prise avec pour objectif le bien être du projet/communauté et non pas celui d'un unique membre de la communauté.
Tu ne verras jamais GNOME ou systemd enlever des parties du projet afin de les rendre propriétaires pour rendre les utilisateurs dépendant et prévenir d'autres boites de fournir des services dessus comme cela a été fait pour influxdb ( voir https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ ) ou les tests dans certains autres projets libres.
Tu ne les verras jamais aussi bloquer les contributions aux projets car cela peut nuire a leurs bénéfices de leurs autres produits proprietaires ou donner certains avantages a leur compétition.
Donc au final concentrer les gens avec les droits de commit peut donner un certain pouvoir qui peut être abusé. Ce n'est pas forcement le cas de toutes les boites, mais la diversité des développeurs et/ou la politique affichée de la boite derrière un projet sont des critères qui aident a mitiger ce risque.
Si le projet m’intéresse et qu'une des entités concentre une majeure partie des développeurs, oui ça peut m’intéresser car cela peut introduire un risque pour moi.
Je suis aussi convaincu que ces entités souhaitent encore avoir des utilisateurs, seulement je ne suis pas sur de toujours faire parti du groupe qu'elles souhaitent avoir, surtout si je ne paye pas.
Lorsque l'on concentre la majeure partie des développeurs dans une même boite, il est très tentant de saisir l’opportunité pour en contrôler son développement et éliminer la concurrence pour le bénéfice de la boite et au détriment de la communauté.
Note: Juste pour être bien clair, cela ne vise pas cozycloud. Je trouve au contraire que cozycloud a été exemplaire.
On utilisait fut en temps logstash -> elasticsearch.
Mais logstash avait du mal a suivre la charge. Apache Flume s'en sortait beaucoup mieux (du genre 10x mieux). Du coup on utilise maintenant Apache Flume avec morphlines qui envoie le tout dans un cluster elasticsearch.
Concernant les alertes on se dirige vers des alertes nagios qui font des requetes sur elasticsearch et alertent en fonction.
Je viens de voir la video en question et je suis decu. Les idees ne sont pas si betes que ca. Elles repondent a un besoin.
C'est pas comme si twitter et instagram sont completement innovantes et geniales.
http://www.freebase.com/view/people/views/person
Ensuite dans filter: "Date of birth value is 1952"
Et hop on peut afficher tout ca sous forme de table, carte, timeline et meme l'export sous son format favoris.
Freebase est quand meme le wikipedia des donnees. A noter que les dumps sont disponibles :)
# Super nouvelle!
Posté par Paf . En réponse au journal Spring Troie est dehors : le cadriciel java n'a plus son talon d'Achille. Évalué à 3.
Ca a l'air d'etre une bonne mise a jour.
Graalvm c'est tres bien pour les outils en ligne de commande ou la reactivite est importante. Mais ca m'interesse moins cote serveur ou je prefere beneficier du potentiel complet de la JVM et de ses optimisations.
# Les vrais ecolos sont uniquement de mon parti
Posté par Paf . En réponse au journal Les vidéos de Devoxx fr sont disponibles. Évalué à 10.
Les attaques personelles et la mise en champ d'un debat simpliste et bebete en mode "moi gentil contre les mechants de pas-mon-parti" deraillent tout le propos du journal, ce qui est dommage.
Toutes les personnes qui ont des choses interessantes a dire sur le sujet sont legitimes.
Rejetter les propos de gens qui ne font pas parti des associations que tu approuves n'aurait pour effet que de creer une chambre a echo et rater d'autres points de vue tout aussi importants et interessants.
Donc en fait, quand tu achetes ton pain a la boulangerie, tu ne paies pas l'electricite? Quand tu achetes un logiciel, tu ne payes pas le salaire des developpers ou de la receptioniste?
Une entreprise a des couts et des revenus. Les couts inclus les salaires, impots, eau, electricite, et meme les repas si ils les servent. De facon a pouvoir pereniser l'entreprise, ces couts sont captures dans les prix de vente et ce que vont payer les clients.
Donc un fournisseur de cloud fera definitivement payer l'electricite utilisee (et les generateurs, et les employes…) dans les datacenters a ses clients.
Je n'ai aucune idee pour clever cloud ou gandi, mais il y a un certain nombre de datacenters et fournisseur de cloud qui sont carbon neutral. Preuve etant qu'il n'y a pas que les membres de ton association d'ecolo qui s'interessent a l'ecologie et le rechauffement climatique.
Il n'y a pas de petites economies en effet.
Mais le probleme souleve dans la video est que c'est un point systematiquement trop mis en avant de facon alarmiste. Et tant qu'a mettre quelque chose en avant, autant mettre quelque chose avec bien plus d'impact.
Il faudrait arreter de s'imaginer des ennemis et ecouter un peu plus ce qu'ils disent dans la video.
Il y avait notamment un point interessant qui disait grosso modo que vu l'impact disproportione des transports et de l'energie, il serait benefique de numeriser pas mal de services de facon a ce que les gens n'aient pas a se deplacer et ainsi reduire leur impact sur l'environnement.
Ca sent surtout le virtue signaling.
Pourquoi s'inventer ces presentateurs en ennemis?
On a la chance d'avoir eu deux personnes qui sont impliques dans le cloud francais s'interesser au sujet, faire de la recherche et de la preparation dessus, proposer leur presentation a la conference et y aller. Au lieu de s'imagine en victime persecute, il serait bien plus interessant d'elever le debat et de se concentrer sur des points tangibles et qui pourraient avoir in impact positif.
[^] # Re: Ça va permettre de comparer deux modèles de développement
Posté par Paf . En réponse à la dépêche Amazon OpenSearch - fruit d'une rivalité avec Elastic ?. Évalué à 4.
Elasticsearch est super basique sur AWS. Il y a pas mal de limitations et ne rend pas la vie facile.
Du point de vu experience utilisateur, la version d'Elastic est a des annees lumiere. Ils ont aussi des opportunites qu'AWS ne pourra jamais explorer (ex: cross-cloud).
Je trouve qu'au contraire cela a beaucoup a voir avec la morale. Elastic avait un melange de code libre et non-libre au sein du meme depot. Ils n'encouragent pas non plus une communaute de developpeurs. En fait, ils ont une position qui n'est pas egale aux autres contributeurs.
Ils veulent surtout le benefice du libre sans les inconvenients de facon a ce que leur produit soit facile a introduire et essayer, mais que l'on soit force de leur payer si on veut utiliser cela en production.
Je comprends l'appetit economique d'Elastic et leur attitude anti-competitive, mais en tant qu'utilisateur de logiciel libre, cela me force a considerer d'autres alternatives libres telles qu'Apache Solr.
[^] # Re: Travail sur soi
Posté par Paf . En réponse au journal Changement de carrière.. Évalué à 2.
N'etant qu'un etranger d'Internet, il est difficile de donner des conseils avec precisions.
Ceci dit, si le probleme n'est pas avec le boulot, changer non seulement de boulot mais aussi de domaine rajoute un gros risque.
Avec ta position actuelle, tu es deja familier avec les differents acteurs, les responsabilites, tu sais quoi faire en cas d'urgence. Avec un nouveau domaine, tout sera a re-apprendre et risque de generer encore plus de stress.
Donc avant de completement changer de boulot, mon conseille serait d'evaluer quels sont les risques que tu mentionnes et comment simplifier ta vie afin de te donner plus d'espace pour que tu puisses addresser tes problemes:
[^] # Re: Alternatives
Posté par Paf . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 2.
Tout a fait! Et c'est l'un des gros avantages de l'ASF!
Ceci dit l'ASF n'est pas completement immunise contre ce genre de tactiques. Voir par exemple tous les coups bas entre les differentes boites liees au big data et comment ils ont fait le forcing pour enlever la clause de diversite pour la graduation de l'incubateur.
[^] # Re: Alternatives
Posté par Paf . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 3.
influxdb-relay est quelque chose d'autre.
Voir https://www.influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ pour plus de details. Mais en gros:
Dans les projets libres que je recommande, je ne regarde pas juste la license du logiciel mais aussi si il y a une communaute autour. Un logiciel libre pousse par une boite sans communaute se rapproche plus d'un shareware que d'un logiciel dans l'esprit du libre. Et note que c'est voulu et admis (de facon semi-ouverte) par la plupart de ces boites.
Et pour rappel, voici ce qu'a dit le CEO de mongodb recemment:
La plupart de ces boites veulent beneficier de l'aura positive des logiciel libres sans pour autant s'y investir completement. Realistiquement, ells vont mettre des barrieres a la contribution tiers.
En tant qu'utilisateur, je veux m'assurer les que les interets des utilisateurs passe en premier pour eviter que d'autres ennuis comme le clustering d'influxdb ne m'arrive. Je veux aussi pouvoir contribuer de facon positive au projet si necessaire et meme beneficier du choix de plusieurs fournisseurs de services si necessaire. Et c'est bien pour ca aussi que le motto non-officiel de l'ASF est "community over code".
[^] # Re: Oss
Posté par Paf . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 2.
Si on prend le cas d'elasticsearch, cela reste tres problematique combien meme le coeur est libre:
Ils ont tout mis dans le meme depot git, que ce soit la partie libre ou la partie pas libre. Du coup ce qui se passe dedans n'est pas forcement clair (ex: si je construit un tar, comment ca se passe?) mais cela rend plus complique toute contribution (ex: j'ai du code a contribute mais ca risque de casser une de leur partie proprio or entre en concurrent).
De meme il n'y a pas vraiment de communaute de developpeurs pour elasticsearch, seulement des utilisateurs. Note: Avoir une visibilite dans les tickets et pr du repository ne compte pas vraiment comme communaute.
[^] # Re: Alternatives
Posté par Paf . En réponse au journal Elastic fait fermer les dépôts SearchGuard sur GitHub. Évalué à 5.
Chronograf est un autre product open core, que je ne compterai pas dans la categorie libre. Pour rappel, les gars d'influxdata, qui sont derriere chronograf, sont les memes qui ont enleve tout code lie au clustering d'influxdb pour le rendre proprietaire et rabaisser le coeur libre.
Elasticsearch n'est que l'enrobage de la bibliotheque Apache Lucene dans un service distribute. Donc on peut arriver a la meme chose avec Apache Solr qu'Elasticsearch. L'avantage d'elasticsearch est qu'il a ete longtemps l'outil le plus facile a deployer et a integrer avec des connecteurs pour tout ce qui est a la mode et le fait que l'on pouvait envoyer des documents sans avoir a definir de schema au prealable. Apache Solr Cloud s'est pas mal ameliore en terme de facilite d'utilisation depuis.
D'ailleurs pour tous mes prochain projets, je vais regarder en premier Apache Solr.
[^] # Re: Code source
Posté par Paf . En réponse au journal Mobicoop, une alternative « libre » à Blablacar. Évalué à 4. Dernière modification le 22 mars 2019 à 22:13.
Le Mossieur a quand meme une bonne remarque sur ce point.
Ce journal et les commentaires defendant mobiscoop mettent beaucoup en avant le fait que ce soit libre, que cela tente de minimiser les couts et avoir un systeme plus humain. Le tout s'opposant a blablacar en evoquant l'argent et autres symboles associes.
Le fait que le code ne soit qu'open core et que ce soit proprietaire en dual license n'est pas du tout en accord avec les valeurs affichees abondamment par mobiscoop.
Si mobiscoop veut etablir un systeme en accord avec ses valeurs affichees, faire du proprietaire y va a l'encontre. Permettre aux gens d'avoir et heberger leur propre version ne peut qu'aller dans le sens de ces valeurs (ex: avoir une instance a l'echelle d'une boite pour aider et encourager les employes a faire du covoiturage). Le proprietaire n'a de sense que dans un contexte ou on essaie de rendre les utilisateurs captifs afin de maximiser le profit.
D'un point de vu potentiel contributeur, cette situation actuelle me fait fuir et eviter de toucher au code a ce projet car du point de vu license c'est le bordel:
* Il y a un badge de license AGPLv3. Cool, ca a l'air d'etre libre
* Je regarde la license https://gitlab.com/mobicoop/mobicoop/blob/dev/LICENSE et ca a l'air d'etre la license standard pour l'AGPLv3.
* La license specifiee dans https://gitlab.com/mobicoop/mobicoop/blob/dev/package.json#L42 indique aussi GPLv3. Donc pour le moment, pas de proprio
* Je vais sur leur doc referencee sur leur README.md ( https://mobicoop.gitlab.io/mobicoop/#/ ) et voir tout en bas:
Donc ce n'est pas AGPLv3 en fait? Ou se trouve cette autre license proprietaire?
Donc ca dit que c'est AGPLv3 ET proprietaire. Mais la encore cette license proprietaire n'est definie nul part. De meme je n'ai vu nul part de Contributor License Agreement (CLA ou son equivalent francais). J'ai aussi regarde quelques merge requests au cas il y a une verification du fait que chaque contributeur donne une license perpetuelle proprietaire a la boite derriere mobicoop, mais je n'ai rien trouve de tel.
Donc au final, je leur souhaite de reussir mais aussi:
* Je serais curieux de comprendre la difference de raisonnement pour le cote proprietaire du code. Je n'ai pas trouve d'explication sur le site
* Je leur conseille de se renseigner plus sur les licenses proprietaires vu qu'en l'etat cela ne me semble pas applicable. Voir a titre d'exemple https://www.elastic.co/contributor-agreement ou https://www.ubuntu.com/legal/contributors ou encore https://www.clahub.com/ . Ceci dit je suis loin d'etre un avocat et tres loin d'etre fan des projets libres qui me demandent le droit d'utiliser mes contributions pour leurs produits proprietaires.
[^] # Re: Community over code
Posté par Paf . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 14 mars 2019 à 09:36.
Il faut tout d'abord separer les differents problemes.
En premier lieu, je ne pense pas que ce soit un bon echange de sacrifier sa liberte pour du code. Si moi ou AWS ne peuvent fournir un service d'hebergement d'elasticsearch, ce n'est pas libre. Donc je ne vois rien de mal a avoir AWS ou autre fournir un tel service d'hebergement.
Ce serait aussi injuste vis a vis des autres projets qui sont au coeur d'Elasticsearch comme netty ou apache lucene. Elastic devrait les remunerer.
Tout ca me rappelle d'ailleurs ce qu'ecrivait RMS il y a presque 30ans: https://www.albertopettarin.it/fsfs2/fsfs2.xhtml#x1-590006
Par ailleurs, AWS l'a demontre avec mongodb: si ca vaut le coup, ils developperont une facade pour supporter le protocole de mongodb sans utiliser une seule ligne de code de mongodb. Donc ca ne protege en rien elastic.
Donc que peut faire Elastic? Ils peuvent se congratuler! Ils sont devenus si populaire et gros qu'AWS leur paie attention. Ensuite ils peuvent accepter qu'Elasticsearch est devenue une commodite. Se fermer et se replier serait une erreur car la communaute l'abandonnerait au profit du fork le plus accueillant (ou Apache Solr) et ne ferait que renforcer sa competition. A la place:
S'ouvrir plus et accepter qu'Elasticsearch est une commodite. Mine de rien Elastic a le plus de contributeurs sur le projet, ce qui lui donne le plus d'influence. Ils baissent la barre pour contibuer a Elasticsearch et ainsi rendre le developpement trop gros/rapide pour un fork.
Redoubler d'efforts sur l'hebergement. Il y a plusieurs opportunites qu'AWS ne pourra jamais supporter comme cross-cloud federation. Ils peuvent aussi s'etendre horizontalement (comme une plateforme) ou verticalement (plutot cote applicatif comme ils ont tente avec un APM). Faciliter son integration avec les domaines en poupes comme le deep learning (ex: tres utile pour chercher a base de vecteur) ou IoT. S'assurer aussi d'une bonne integration avec les bibliotheques et cadres populaires (spring, react, ruby, etc.)
Monter au prochain niveau d'abstraction avec une strategie open core. Etablir une separation claire et nette entre la commodite (elasticsearch) et la partie proprietaire qui sera au dessus. Ca permet de non seulement garder la communaute, mais de l'etendre tout en beneficiant de ses avancees
Reduire le pouvoir d'AWS avec un investissement dans les technologies cloud agnostic. Genre s'assurer une bonne integration avec Kubernetes
Quant au financenent en general, c'est assez vague. Mais si elasticsearch n'existait pas, tout le monde utiliserait Apache Solr :)
La difference de popularite s'explique surtout a la facilite d'utilisation d'elasticsearch a mon avis.
Un gros facteur ici est le fait qu'Elastic a recu pas mal d'investissements, ce qui rajoute pas mal de pression pour des retours.
Un autre example serait aussi de regarder et s'inspirer d'autres gros projets qui ont beaucoup de succes et ont du developpement finance par plusieurs entreprises:
[^] # Re: Community over code
Posté par Paf . En réponse au lien Elastic Search préforké. Évalué à 2.
Et c'est un probleme?
Il y avait la meme question lorsqu'Oracle voulait donner OpenOffice a la fondation Apache. Il existait deja LibreOffice et la reputation d'Oracle n'etait pas franchement bonne. Donc c'etait quoi l'interet de jouer le jeu et de l'accepter?
La position de l'ASF est que ce n'est pas un investisseur ou ne specule pas sur les projets. Ils ne font que fournir un cocon pour aider les projets a se gerer. Donc ils ne vont pas juger en se basant sur les chances de success.
L'interet est que l'on se retrouve avec le choix:
Et du point de vus succes, la fondation Apache n'a rien d'une poubelle. Rien que le poids financier des projets genre Apache Hadoop/hbase/spark/mesos/flink/lucene/solr/camel se compte en millards de dollars. Ou je pourrais aussi mentioner l'impacte que d'autres projets ont sur l'ecosysteme entier comme Apache Httpd, Maven, ivy, commons, groovy
[^] # Community over code
Posté par Paf . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 12 mars 2019 à 23:46.
Je pense que cette situation est le resultat d'une communaute qui n'est pas saine et ne remet pas en cause le financement de projets libres.
D'autant plus qu'Elastic a aussi un service d'hebergement pour Elasticsearch qui se porte plutot bien.
Le probleme ici est que Elastic a un controle total sur le projet et qu'ils ont commence a en profiter pour leur avantage, au detriment du projet lui-meme et de sa communaute.
Ce n'est pas la premiere fois et ce ne sera pas la derniere fois non plus. Voir entre autre:
Parfois ca passe, parfois ca fork ou parfois le projet se meurt.
En general cela repose sur le fait que la partie libre n'est qu'une version shareware deguisee. C'est tres bien pour experimenter et meme avoir des contributions externes (avec attribution a la boite derriere le projet bien entendu, au cas ou ils veulent changer la license…), mais il faut soit passer a la caisse quand on veut passer en production ou avoir la capacite technique de le faire soi-meme (et qui a un certain cout).
Si l'on rajoute a ca le fait que tout ce qui irait a l'encontre de la boite derriere le projet serait rejete ou rendu impossible, la situation actuelle n'est pas vraiment ideale pour un ecosysteme libre et sain.
Donc le fait qu'AWS pousse vers une remise a niveau n'est pas un mal en soit. C'est une opportunite de rendre le projet plus libre. J'imagine qu'a ce niveau, soit Elastic reste tetu est essaye de resister, soit ils coupent l'herbe sous le pied d'AWS et donnent le projet a l'ASF ou il deviendra plus neutre.
Faire rentrer le projet a l'ASF serait vraiment bien. Il ne peut pas y avoir de co-opetition si les acteurs ne sont pas au meme niveau et c'est exactement ce que fournit la fondation Apache. D'ailleurs on entend souvent "community over code" pour souligner le fait qu'avoir une communaute saine est beaucoup plus important que le code.
Et meme si ce n'est pas parfait, ils ont fait un bon boulot. On peut voir plusieurs entreprises supportant Apache Hadoop, plusieurs entreprises derriere Apache Lucene et Solr et se portent toutes tres bien.
Donc non, le fait que le createur d'Elasticsearch bosse a Elastic ne donne pas le droit a Elastic d'etablir une rente a vie sur du logiciel libre.
[^] # Re: Deux interprétations
Posté par Paf . En réponse au journal [bookmark] Privacy Shield subira-t-il le sort de Safe Harbor ?. Évalué à 2. Dernière modification le 08 octobre 2017 à 23:54.
Les donnees des utilisateurs ne traversent pas l'atlantique dans le but unique de pouvoir revendre les donnees. Il y a aussi l'aspect pratique et technique.
Ne pas avoir a se soucier du pays d'origine des utilisateurs (Internet sans frontieres!) permet d'eviter tout un tas de problemes techniques tels que:
Donc a moins que ne ce ne soit un besoin fortement exprime par les utilisateurs ou une contrainte imposee par la loi, les boites n'ont pas vraiment de raison de separer les donnees par continent/pays.
[^] # Re: des pistes
Posté par Paf . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2.
Je recommande quand même la même chose d'un point de vu général pour faciliter les contributions. Et aussi d'avoir un readme à la racine de ton dépôt avec un lien vers le site et les instructions de construction.
Du point de vu légal je n'ai rien a rajouter. Il faudrait lister et voir toutes les licences de tes dépendances.
[^] # Re: des pistes
Posté par Paf . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2. Dernière modification le 28 février 2017 à 07:22.
si tu n'utilisais pas play, j'aurais recommendé Apache Maven ou gradle (perso hé préfère Apache Maven) pour gérer ton projet.
# des pistes
Posté par Paf . En réponse au message Publication d'une application libre : comment faire avec des bibliothèques et des dépendances ?. Évalué à 2.
Ce que je recommenderai:
* regarde du côté de https://www.playframework.com/documentation/2.5.x/Deploying pour construire une archive de déploiement avec les dépendances.
* automatiser le build et les tests. Il y a travis ou circle ci qui fournissent des services de construction gratuits pour les projets libre. Sinon gitlab fournit des cela aussi. Cela à plusieurs avantages, notamment l'assurance de savoir que ton projet puisse être construit pars des contributeurs et de savoir quand un commit casse la construction ou des tests.
Après pour aller plus loin, voir :
* scripts de déploiements pour les différents services. Par exemple ansible ou puppet
* images docker et/ou intégration avec kubernetes. Mais pas tout le monde utilisé pas encore.
[^] # Re: La version officielle
Posté par Paf . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 7.
La différence se trouve principalement que l’intérêt d'une boite n'est pas nécessairement le même que celui de la communauté et qu'elle a aussi un poids surdimensionne dans les décisions.
Même si GNOME ou systemd ont pris des décisions que l'on apprécie pas, elles ont toutes ou presque été faites a la suite de discussions et/ou votes (ex: https://lists.debian.org/debian-ctte/2014/02/msg00294.html ). Par ailleurs les décisions ont ete prise avec pour objectif le bien être du projet/communauté et non pas celui d'un unique membre de la communauté.
Tu ne verras jamais GNOME ou systemd enlever des parties du projet afin de les rendre propriétaires pour rendre les utilisateurs dépendant et prévenir d'autres boites de fournir des services dessus comme cela a été fait pour influxdb ( voir https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ ) ou les tests dans certains autres projets libres.
Tu ne les verras jamais aussi bloquer les contributions aux projets car cela peut nuire a leurs bénéfices de leurs autres produits proprietaires ou donner certains avantages a leur compétition.
Donc au final concentrer les gens avec les droits de commit peut donner un certain pouvoir qui peut être abusé. Ce n'est pas forcement le cas de toutes les boites, mais la diversité des développeurs et/ou la politique affichée de la boite derrière un projet sont des critères qui aident a mitiger ce risque.
[^] # Re: La version officielle
Posté par Paf . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 4. Dernière modification le 20 juillet 2016 à 21:30.
Si le projet m’intéresse et qu'une des entités concentre une majeure partie des développeurs, oui ça peut m’intéresser car cela peut introduire un risque pour moi.
Je suis aussi convaincu que ces entités souhaitent encore avoir des utilisateurs, seulement je ne suis pas sur de toujours faire parti du groupe qu'elles souhaitent avoir, surtout si je ne paye pas.
Lorsque l'on concentre la majeure partie des développeurs dans une même boite, il est très tentant de saisir l’opportunité pour en contrôler son développement et éliminer la concurrence pour le bénéfice de la boite et au détriment de la communauté.
Note: Juste pour être bien clair, cela ne vise pas cozycloud. Je trouve au contraire que cozycloud a été exemplaire.
[^] # Re: Loganalyzer
Posté par Paf . En réponse au message Logiciel de supervision de log KISS, avec remontée d'alerte. Évalué à 1.
Pour la partie analyse ou remontee de logs?
As-tu essaye lumberjack pour la remontee de logs?
[^] # Re: systeme de monitoring
Posté par Paf . En réponse au message Logiciel de supervision de log KISS, avec remontée d'alerte. Évalué à 1.
On utilisait fut en temps logstash -> elasticsearch.
Mais logstash avait du mal a suivre la charge. Apache Flume s'en sortait beaucoup mieux (du genre 10x mieux). Du coup on utilise maintenant Apache Flume avec morphlines qui envoie le tout dans un cluster elasticsearch.
Concernant les alertes on se dirige vers des alertes nagios qui font des requetes sur elasticsearch et alertent en fonction.
[^] # Re: La France ce n'est pas les USA
Posté par Paf . En réponse au journal Aller bosser à San Francisco. Évalué à 1.
Du genre?
Il y a moult choses a faire dans le sud de la baie.
[^] # Re: La France ce n'est pas les USA
Posté par Paf . En réponse au journal Aller bosser à San Francisco. Évalué à 1.
Trou paume, trou paume… c'est quand meme pas si paume que ca entre Palo Alto, Mountain View et San Jose :)
[^] # Re: rigolade
Posté par Paf . En réponse au journal Entretiens du nouveau monde industriel 2012. Évalué à 5.
Je viens de voir la video en question et je suis decu. Les idees ne sont pas si betes que ca. Elles repondent a un besoin.
C'est pas comme si twitter et instagram sont completement innovantes et geniales.
[^] # Re: Pour le lancement du jar
Posté par Paf . En réponse au journal Write once, run anywhere qu'il disait. Évalué à 5.
Ca peut aussi aider a traquer le pid si besoin est.
[^] # Re: Super
Posté par Paf . En réponse à la dépêche Wikidata : Wikipedia comme une base de données. Évalué à 2.
http://www.freebase.com/view/people/views/person
Ensuite dans filter: "Date of birth value is 1952"
Et hop on peut afficher tout ca sous forme de table, carte, timeline et meme l'export sous son format favoris.
Freebase est quand meme le wikipedia des donnees. A noter que les dumps sont disponibles :)