Paf a écrit 109 commentaires

  • [^] # Re: Code source

    Posté par . En réponse au journal Mobicoop, une alternative « libre » à Blablacar. Évalué à 4. Dernière modification le 22/03/19 à 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:

    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?

    /**
    * 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.

  • [^] # Re: Community over code

    Posté par . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 14/03/19 à 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:

    • Gnome
    • Apache Spark
    • Apache Flink
    • Apache Kafka
    • Apache Hadoop ecosysteme
    • Apache Lucene
    • Nextcloud
  • [^] # Re: Community over code

    Posté par . 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:

    • 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

  • [^] # Community over code

    Posté par . En réponse au lien Elastic Search préforké. Évalué à 3. Dernière modification le 12/03/19 à 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.

  • [^] # Re: Deux interprétations

    Posté par . En réponse au journal [bookmark] Privacy Shield subira-t-il le sort de Safe Harbor ?. Évalué à 2. Dernière modification le 08/10/17 à 23:54.

    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.

  • [^] # Re: des pistes

    Posté par . 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 . 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/02/17 à 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 . 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 . 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 . En réponse au journal Cozy cloud, maif et licenciement du CTO???. Évalué à 4. Dernière modification le 20/07/16 à 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 . En réponse au message Logiciel de supervision de log KISS, avec remontée d'alerte. Évalué à 1.

    Logstash est très beau mais c'est tout ce qu'il y a de moins KISS (charge CPU et MEM importante). Pas adapté à une petite structure.

    Pour la partie analyse ou remontee de logs?
    As-tu essaye lumberjack pour la remontee de logs?

  • [^] # Re: systeme de monitoring

    Posté par . 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 . 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 . 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 . 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 . 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 . 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 :)

  • [^] # Re: Kouakece ?

    Posté par . En réponse au journal Un AppStore est-il viable pour une distribution Linux ?. Évalué à 1.

    Note que ce n'est pas aussi complique ou misereux que ce qui est laisse entendre. Loin de la.

  • [^] # Re: un fichier pour les gouverner tous... mon precieux....

    Posté par . En réponse au message Installateur packaging. Évalué à 2.

    Si tu veux faire des paquets:
    * Chaque distribution a ses regles de paquetage. Pour fedora, voir par exemple https://fedoraproject.org/wiki/Packaging:Guidelines et https://fedoraproject.org/wiki/Packaging:Java
    * Regarde du cote de https://build.opensuse.org/ qui te fourni un service gratuitement pour faire des paquets pour les distributions GNU/Linux les plus connues
    * Pour gerer ton projet, je te conseille de regarder du cote de maven :)
    * le jre ne doit pas etre dans les dependances. Ton paquet dependra sur un truc du genre "Requires: java".
    * Les distributions GNU/Linux fournissent au moins openJDK. Donc je ne me soucierai pas trop de la presence ou non de la JRE.

  • [^] # Re: Kouakece ?

    Posté par . En réponse au journal Un AppStore est-il viable pour une distribution Linux ?. Évalué à -1.

    Dans le pire des cas weboob-havesex n'est pas dans les depots par defaut. Mais cela ne les empeche pas de le fournir via des depots alternatifs.
    Tout comme Amazon et autres ont des depots alternatifs a android.

    Alors que dans le cas d'Apple, si ils te refusent, tu ne pourras rien distribuer du tout, que je sache.

  • [^] # Re: Kouakece ?

    Posté par . En réponse au journal Un AppStore est-il viable pour une distribution Linux ?. Évalué à 1.

    Donc au final les quelques uns qui s'y essaye sont par exemple dropbox, dont le .deb télécharge toutes les libs et binaire dans le ~/.dropbox-dist car ils évitent 3 tonnes d'emmerdes selon les distribs. Et économiquement c'est valable car tu payes le service dropbox pas l'app en elle même…..

    C'est une enorme generalisation a deux balles.

    Il est parfaitement possible de fournir des paquets pas trop degueu et sans trop d'emmerdes pour plusieurs distributions a la fois.
    Le soucis que j'ai le plus rencontre sont lies aux implementations buggees de la LSB. Mais ce genre de soucis n'existe plus vraiment.

  • [^] # Re: Proposition de traduction

    Posté par . En réponse à la dépêche Logiciel libre et Big Data. Évalué à 1. Dernière modification le 17/03/12 à 12:59.

    Sauf que maintenant les marketeux commencent à parler d'eXXXtriiiime data.
    D'ailleurs le terme "données extrêmes" sonne mieux!

  • [^] # Re: Base de données Logiciel libre et Big Data

    Posté par . En réponse à la dépêche Logiciel libre et Big Data. Évalué à 1.

    Pas vraiment a propos du document, mais a noter aussi la premiere reunion du groupe d'utilisateur d'Apache Hadoop France a Paris demain:
    http://fr.amiando.com/GETAYVM.html?page=696595

  • [^] # Re: Base de données Logiciel libre et Big Data

    Posté par . En réponse à la dépêche Logiciel libre et Big Data. Évalué à 2.

    A rajouter dans la liste: Apache Gora http://gora.apache.org/

  • # Base de données Logiciel libre et Big Data

    Posté par . En réponse à la dépêche Logiciel libre et Big Data. Évalué à 3. Dernière modification le 14/03/12 à 21:54.

    Bon boulot!
    Meme si j'aurai bien aime voir un diagramme facon "couche d'os" montrant quels sont les projets qui font quoi. Par exemple avec Apache HAdoop au centre, puis les projets gravitant autour permettant de gerer les jobs, importer les donnees en flux, importer/exporter les donnees depuis les bases de donnees, bases nosql…

    Il serait admirable aussi d'introduire des cas d'utilisation. Voir ceux decrits dans les differents blogs et conferences (Hadoop summit, Hadoop World…)

    De meme, des informations concernant comment sont utilises se soutils serait un plus. Par exemple pour Apache Hadoop on passe soit par du code java, C/C++ via pipes, ou n;importe quel executable via stdin/stdout.
    Mais du fait de la complexite/bas niveau du concept MapReduce, des outils d'abstration tels que Hive ou Pig ont vu le jour.

    De manière similaire, on voit se développer des besoins importants, et des projets matures, dans
    les domaines de la gestion de parc, du déploiement automatique, du monitoring, etc. Parmi les
    projets significatifs, citons: Chef, Puppet, Fabric, Zookeeper, etc.

    Pourquoi mettre Apache Zookeeper dans ce sac?
    Apache Zookeeper fourni un framework pour coordonner des processus distribues.
    Donc je vois comment on pourrait le mettre dans la categorie "infrastructure", mais tout de meme pas au meme niveau que chef/puppet

    Dans les clones de BigTable, on pourrait rajouter Apache Accumulo qui a ete developpe par la NSA puis soumis recemment pour incubation a la fondation Apache.

    Dans la categorie des moteurs d'indexation et de recherche, il existe aussi blur. Voir http://www.blur.io/

    Sinon il manque Hue qui sert d'interface web pour les utilisateurs (lancer des jobs, requetes Hive, pig…), Apache Hive, Apache Pig, Apache sqoop pour pouvoir transferer les donees depuis des bases de donnees vers Apache HAdoop, Apache Oozie pour la coordination de workflow, Apache Whirr pour la creation de clusters dans le cloud et Apache Bigtop (en incubation) qui sert de point d'integration a tous ces projets BigData centres sur Apache Hadoop en fournissant les choses suivantes :

    • Des paquets/depots pour les distributions GNU/Linux les plus populaires (fedora, centos, debian, ubuntu, mageia, openSUSE, SLES)
    • Des recettes de deploiements (recettes puppet, creation de VM, creation de bootable live cd/usb)
    • Un framework de test ainsi que des tests d'integrations pour tous ces composants Au final Apache Bigtop permet de fournir et valider un stack complet repondant aux besoins du BigData. A noter par ailleurs que Apache Bigtop (en incubation) a ete donne a la fondation Apache par Cloudera et ser de base a CDH4.