Elastic, l’entreprise derrière Elasticsearch, Logstash et Kibana, fait fermer les dépôts GitHub de SearchGuard, une extension de sécurité pour Elasticsearch sous le motif d’avoir copié le code propriétaire de X-Pack (rendu publique il y a quelques mois).
Floragunn, l’entreprise derrière SearchGuard, s’est défendu sur son blog d’avoir enfreint les droits d’Elastic.
Le dernier paragraphe de l’annonce d’Elastic est particulièrement croustillant (l’emphase est de moi) :
All Search Guard users are a part of the Elastic community, and it is unfortunate that floragunn’s actions may have put you in the position of running infringing code. As you consider your options, please be aware that Elasticsearch now includes free security features by default, which will help ensure you don’t need to run an unprotected cluster. We want to help, so please reach out to us at search-guard@elastic.co if you have questions.
En fait c’est de ça qu’il s’agit, Elastic fait fermer les dépôts d’un concurrent sous des motifs fallacieux. Et c’est tellement simple (j’aurai pu écrire la lettre de DMCA moi même) que ça fait peur.
Anecdote personnelle, j’avais assisté à une conférence d’un employé d’Elastic lors d’un Meetup Kubernetes à Montréal qui parlait d’Open Code (comprendre : c’est pas de l’open source parce que ça nous fait chier, mais on veut quand même la hype qui va avec).
# Elsa tique
Posté par Thomas Debesse (site web personnel) . Évalué à 8.
Mon commentaire ne répond pas sur le fond mais il y a plus d’occurrences d’Elsatic que d’Elastic dans ton journal ! Je ne sais pas d’où vient ce lapsus mais il est intéressant ! 🙃
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Elsa tique
Posté par Anonyme . Évalué à 2.
Haha, c'est juste des typos. Je veux bien qu'un modérateur corrige.
[^] # Re: Elsa tique
Posté par El Titi . Évalué à -5.
Plus sérieusement, je t'invite à visionner cette vidéo avant d ete lancer dans ta diatribe freewashing.
Voilaaa!
[^] # Re: Elsa tique
Posté par Anonyme . Évalué à 10.
J’ai regardé la vidéo et franchement, j’ai un mauvais pressentiment sur l’avenir du logiciel libre.
Déjà, ça m’énerve ce discours « ouin ouin, les gens y reprennent notre code et y paye même pas ». C’est le putain de deal quand tu fais du libre, fallait faire du proprio si tu voulais qu’on te paye des licences. Ah ben non, le proprio ça se vend pas aussi bien.
Ensuite, j’ai récemment vu beaucoup de monde se demander si un changement vers du « libre sous condition » ne serait pas bénéfique. Par exemple parce que du logiciel libre est utilisé par l’ICE aux États-Unis, ou alors parce que Google et Amazon sont des crevards qui s’engraisse sur le dos des développeurs du libre (bénévoles ou non).
Je pense sincèrement qu’on va se tirer une balle dans le pied à faire ça. Parce qu’à vouloir bloquer Google, on bloquera aussi Framasoft. À vouloir bloquer l’ICE, on bloquera aussi les associations qui se battent pour les migrants.
Et dans tout ça, c’est Google et AWS qui se présenteront comme les grands défenseurs du libre et ils auront gagné.
Trouvons un moyen de défoncer Google, AWS et l’ICE, ça fera plus de bien que de se défoncer nous même.
[^] # Re: Elsa tique
Posté par Toufou (site web personnel) . Évalué à 6.
Résumer le libre à un modèle de diffusion montre clairement que le mec qui a écrit la présentation a raté un aspect majeur du libre : encadrer l'usage d'un logiciel revient à définir ses fonctionnalités.
La licence est une fonctionnalité qui défini entre autre un modèle de diffusion.
La présentation est empreinte de business prédateur, celui malheureusement majoritaire, où les buts sont d'avoir la rentabilité maximum et donc de devenir leader d'un marché quasi monopolistique.
Dans ce cas, oui le libre n'est pas adapté car le libre ne permet pas de verrouiller un monopole (c'est une de ses principales fonctionnalités) : si on veut devenir monopolistique ou presque, il ne faut pas choisir le libre.
De là a dire qu'il n'est pas viable de faire du libre…
[^] # Re: Elsa tique
Posté par El Titi . Évalué à -7.
Et ce n'est pas comme si ce cher Arcaik s'était lancé dans la "Libre Entreprise" avant de déblatérer à tout va!
Quels sont ses risques ?
[^] # Re: Elsa tique
Posté par Anonyme . Évalué à 3.
Et tu le sais parce que ?
[^] # Re: Elsa tique
Posté par El Titi . Évalué à 5.
En effet !
Je reviens sur cette attaque inutile et purement basée sur l'émotion.
Comme on ne peut éditer ses contributions, je te présente donc mes excuses !
[^] # Re: Elsa tique
Posté par El Titi . Évalué à 2. Dernière modification le 21 septembre 2019 à 01:13.
Elsaaaa Fraulein, de l'autre coté
[^] # Re: Elsa tique
Posté par gUI (Mastodon) . Évalué à 2.
Fait, merci.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Elsa tique
Posté par zurvan . Évalué à 4.
Il faudrait aussi corriger : "sous le motif d’avoir copi*er* le code propriétaire" => "sous le motif d'avoir copi*é*…"
(markdown merde toujours autant…)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Elsa tique
Posté par gUI (Mastodon) . Évalué à 2.
Fait, merci
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# En outre...
Posté par Elfir3 . Évalué à 5.
On notera, de mémoire:
Pour les anglophiles, la lecture de la plainte est très intéressante. Je laisserai les extraits de code à votre humble appréciation.
Par contre, sous-entendre qu'Elsatic, devant l'arrivée du grand Amazon, ai conclu un accord avec ce dernier pour évincer la concurrence en échange d'un respect minimum mutuel, ce serait un peu exagéré ؟
[^] # Re: En outre...
Posté par Az' (site web personnel) . Évalué à 1. Dernière modification le 21 septembre 2019 à 09:46.
il y'a quand même pas mal de contributions de floragunn dans opendistro
https://github.com/opendistro-for-elasticsearch/security-kibana-plugin/search?q=floragunn&unscoped_q=floragunn
https://github.com/opendistro-for-elasticsearch/security/search?q=floragunn&unscoped_q=floragunn
je ne crois pas qu'amazon puisse remplacer par le code d'elastic ouvert depuis qui doit être sous leur licence propriétaire.
[^] # Re: En outre...
Posté par Elfir3 . Évalué à 3.
Le code d'Open Distro est bien en partie celui de Floragunn, mais je ne pense pas qu'ils aient utilisé le code sous copyright. Il se sont sans doute basé sur la version floss pour la faire.
Et il n'est absolument pas question d'utiliser le code du X-pack, ils ont leur propre équivalent.
[^] # Re: En outre...
Posté par claudex . Évalué à 4.
Ce qu'ils justifient en disant qu'ils ont décompilé le code. Vu que ça tourne sur la JVM, la décompilation est assez aisée.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par Kerro . Évalué à 1. Dernière modification le 22 septembre 2019 à 18:42.
Je n'ai pas compris cette partie.
Que ce soit facile n'implique pas que ce soit légal : par exemple il est facile de faire un excès de vitesse en automobile.
[^] # Re: En outre...
Posté par claudex . Évalué à 3.
Je ne comprends pas du tout ta remarque. Je dis que c'est aisée et que donc c'est tout à fait imaginable qu'ils l'aient fait sans trop de problèmes et qu'ils ont donc bien pu violer le droit d'auteur avant que les sources soient publiées.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par Elfir3 . Évalué à 1. Dernière modification le 22 septembre 2019 à 22:24.
D'où le "mais sans doute récupéré via décompilation". Mais le fait que ce soit du code pour la JVM aide, en effet.
[^] # Re: En outre...
Posté par Karnag . Évalué à 1.
J'ai eu la chance de rencontré Jochen Kressin, CEO et Co fondateur de SG à plusieurs reprises. https://www.linkedin.com/in/jkressin/
Ce mec c'est un crack, spécialisé en sécu,
Quand on regarde la timeline de la création d'un solution de sécu par Floragunn VS ce qu'a pu faire ES on voit qu'ils avaient déjà une longueur d'avance. Rien qu'a regarder depuis quand la communication inter-serveur est sécurisée via TLS dans les 2 cas (c'est la moindre des choses dans des transferts de data, non ?). https://search-guard.com/elasticsearch-security-free-search-guard/
Pour moi c'est un pur "dick move" de la part d'ES, deal ou pas avec AWS.
L'équipe de Redis, qui n'a peut-être pas choisit la bonne réponse (https://www.zdnet.com/article/redis-labs-and-common-clause-attacked-where-it-hurts-with-open-source-code/ et https://www.techrepublic.com/article/why-redis-labs-made-a-huge-mistake-when-it-changed-its-open-source-licensing-strategy/) - a, de mémoire, eu marre que les GAFAM se gavent sur leurs techno (parfois en rebrandant la techno simplement) et ne contribuent pas ou très peu et ne reverse pas une partie de leurs gain aux dev, parfois bénévoles dans le domaine de l'OpenSource.
C'est la tendance pour moi côté OpenSource pour ces prochaines années.
[^] # Re: En outre...
Posté par barmic 🦦 . Évalué à 2.
Je sais pas trop. Selon le profile de ta charge tu ne peux pas forcément faire du TLS ou en tout cas pas sans avoir un F5 devant chaque machine, mais du coup c'est entre tes nœuds et ton F5 que tu sécurise pas… Sincèrement je ne suis pas un crack et je ne fais pas forcément bien les choses, mais j'ai déjà rencontré des cas où je ne vois pas comment mettre en place du TLS sans complètement exploser sous la charge.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En outre...
Posté par claudex . Évalué à 3.
Je ne vois pas, avec des CPU actuels (qui ont notamment des instructions dédiés pour l'AES), comment tu fais pour avoir des problèmes de charge avec TLS. Surtout pour de la communication entre un faible nombre de machine. Si tu as un cas d'exemple, je suis vraiment preneur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par barmic 🦦 . Évalué à 2.
Je vais le dire de manière plus exacte. Je ne suis pas certain de voir l'intérêt de ce genre d'architectures :
(où on voit en vert tout ce qui est TLS et en rouge tout ce qui n'est pas chiffré)
Il faut vraiment craindre d'avoir des informations critiques en base qui ne viennent pas des utilisateurs (et qui ne leur sont pas transmises). Je ne doute pas que ça existe, mais c'est pas un cas courant amha.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En outre...
Posté par claudex . Évalué à 3.
Je ne vois pas pourquoi les flux en rouge ne serait pas chiffrés. L'avantage du tout chiffré, c'est d'éviter que la moindre machine qui voit passer le trafic (comme un switch) puisse le stocker/dévier pour le lire. Ça protège aussi d'un admin malveillant d'une de ses machines (pas des admin des machines où le trafic est déchiffrés bien sûr). Ça permet aussi d'autentifier tes machines. Pour être sûr qu'il n'y a pas un malin qui a spawner une machine et puisse récupérer les données.
Après, je réagissais principalement sur les performances. Le tout TLS est pour moi loin d'être la principale priorité sur la plupart des infra. Et la gestion de l'expiration des certificats est bien plus problématique pour moi que les performances.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 26 septembre 2019 à 15:11.
Généralement si tu t'achète un F5 plusieurs dizaines de milliers d'euros, c'est parce que tu ne sais pas gérer ta charge TLS. L'exemple le plus récent pour moi c'est d'avoir des dizaines de milliers de mobiles qui viennent te faire une requête. Non seulement ils sont nombreux, mais ils ont tendance à consommer longtemps tes sockets parce qu'ils sont pas sur un réseau haut débit.
L'existence même de F5 ou le prix qu'AWS vend ses ELB1 montre que c'est une vraie problématique.
Après on est d'accord qu'avoir du TLS à tous les étages a pleins d'avantages. J'en suis absolument convaincu. C'est juste que je vois "facilement" les cas où ça paraît difficilement faisable (on peut toujours acheter plus de machines plus grosses).
Ah oui avec une vraie PKI c'est encore autre chose :)
il faut regarder les ELB avec trafic garanti sinon ça coûte rien ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En outre...
Posté par claudex . Évalué à 3.
Perso, j'ai servi facilement 200Mbps de trafic avec un nœud arm chez scaleway il y a 2 ou 3 ans. C'est pour ça que je vois mal la question de la perf.
Perso, les gens que j'ai vu acheté du F5 récemment, c'était pour la sécurité (genre filtrage de client), pas pour les perfs. Des dizanes de milliers de mobile, 4a me semble assez facile de répartir avec un load-balancer tcp en front avant d'avoir les front qui exposent le TLS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par barmic 🦦 . Évalué à 2.
Le débit ça coûte rien. C'est du chiffrement symétrique si je ne m'abuse. Il te faut juste un gros CPU. Ce qui peut te flinguer c'est par exemple l'ouverture de connexion. Ouvrir 10k connexions TLS par seconde ça commence à demander de l'entropie, du chiffrement asymétrique pour l'échange de clef, de la validation de certificat, de la deserialisation de certificats1,… Tout ça va impacter sensiblement ta latence.
En IPv4 (c'est pas ma décision), ton loadbalancer va devoir gérer du NAT, ce qui va lui demander pas mal de RAM, mais oui ça consiste à multiplier ton nombre de machines. C'est un choix ça a un coût, ça se calcul.
Mon point n'est pas forcément de dire que c'est impossible juste que ce n'est pas aussi évident que « c'est un minimum ». Ce n'est pas forcément trivial à mettre en place selon le contexte.
je ne l'avais pas benché et je ne pensais pas que ça puisse poser problème, mais ça a l'air d'être sensible https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En outre...
Posté par claudex . Évalué à 4. Dernière modification le 26 septembre 2019 à 16:27.
Je suis d'accord que ça a un coût. Mais l'exemple que tu donne montre qu'il fait 1300 handshakes par seconde sur une machine assez petite. Donc même 10k, ça ne doit pas être difficile à atteindre. Surtout que si tu as 10k sessions par secondes, ton infra derrière doit encaisser aussi le trafic hors chiffrement.
Là, je ne vois pas. Ton loadbalancer reçoit une connexion et en ouvre une autre. Je ne vois pas où est le NAT dans l'histoire. C'est même un moyen de se "passer" de NAT.
En gros, le nat, c'est 32 bits d'IP sources, 16 bits de ports multiplié par deux pour la traduction. Ça fait donc 96bits par session. Donc pour 10k connexions, tu es à 110Kio. Si tu ajoute un timestamp pour les faire expirer, ça fait 160bits par connexion et on approche des 200Kio.
Je suis d'accord qu'il ne suffit pas de faire apt-get install openssl. Mais ça ne semble pas non plus hors de portée de la plupart des gens sérieux.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par voxdemonix . Évalué à 0.
OpenVPN utilise TLS et ses limitations sont facilement testable avec pivpn et wget.
[^] # Re: En outre...
Posté par claudex . Évalué à 4.
OpenVPN utilise UDP par défaut (et donc pas TLS), donc tu ne va pas tester les performances de TLS. wget tout seul utilise TLS si tu télécharge depuis un site en HTTPS et tu verra que tu obtiens des perfs bien meilleurs en TLS sans passer par OpenVPN.
(La consommation de ressource d'OpenVPN est connue et n'est pas lié à TLS mais à l'architecture et au switch kernel/user mode)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par voxdemonix . Évalué à 2. Dernière modification le 26 septembre 2019 à 15:01.
Ah, tu as en partie raison : "As such, we believe TLS is an excellent choice for the authentication and key exchange mechanism of a VPN product." (source)
Ce qui explique pourquoi "TLS" revient régulièrement dans les logs d'OpenVPN.
[^] # Re: En outre...
Posté par barmic 🦦 . Évalué à 1.
Je ne me suis pas vraiment penché dessus, mais de ce que j'ai compris des micro présentation il semble que HTTP/3 soit UDP+TLS (ne me demande pas comment c'est possible).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: En outre...
Posté par claudex . Évalué à 3. Dernière modification le 26 septembre 2019 à 16:14.
À ma connaissance, TLS est n'est pas utilisé dans HTTP/3 mais est modifié pour fonctionner avec QUIC (à la manière de DTLS).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par Anonyme . Évalué à 2.
UDP et TLS ne sont pas antinomique : Datagram Transport Layer Security.
Et de mémoire, OpenVPN n’utilise TLS que pour le le canal de contrôle, pas pour le canal des données (qui sont chiffrées différemment).
[^] # Re: En outre...
Posté par claudex . Évalué à 3.
DTLS n'est pas TLS. Même si c'est bien sûr très proche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: En outre...
Posté par Benjamin Henrion (site web personnel) . Évalué à 5.
"Delaware et Hollande", ca sent l'évasion fiscale à plein nez.
# Oss
Posté par Rico Belo . Évalué à 7.
Toutes les outils elastic (elasticsearh, logstash, beats) sont disponibles *aussi en saveur oss sous licence apache 2.
Perso, après avoir lu leur licence elastic, j'ai banni cette dernière et réorganisé mes projets utilisant elastic afin qu'ils se content des versions oss…
Certes ça ne résoudre pas la question x-pack vs searchguard, et on est d'accord que le procédé employé ici est clairement dégueulasse… Mais je voulais tout de même rappeler que le core est bel et bien libre.
[^] # Re: Oss
Posté par Paf . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Oss
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 22 septembre 2019 à 14:30.
Comme bien même !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# motif fallacieux ?
Posté par zurvan . Évalué à 10.
Je ne comprends pas trop, pourquoi un motif fallacieux ? Ce n'est pas parce qu'ils disent que la fonctionnalité incriminée est maintenant dans leur code que c'est pour cette raison qu'ils ont fait fermer le concurrent. L'argument d'avoir la fonctionnalité, c'est plutôt pour signifier à leurs clients : "arrêtez d'utiliser le produit concurrent qui bafoue notre licence, utilisez plutôt l'original qui fait la même chose maintenant".
La raison évoquée c'est que du code proprio rendu public a été utilisé chez ce concurrent :
et qu'en plus des éléments de code ont été retrouvé avant la publication, chez ce même concurrent, alors que le code n'avait pas encore été rendu public, ce qui leur fait penser que les concurrents ont décompilé leurs binaires (je ne vois rien de mal à ça, je ne sais pas si c'est légal ou pas…) :
Je ne sais pas si ce qui est dit dans leur lettre est vraie ou pas, mais ça me semble justifier la demande de fermeture, et l'ouverture d'un procès. Je ne connais aucune des deux parties et je n'utilise aucun des logiciels évoqués, c'est juste une question de logique. On trouverait normal de faire un procès à une boîte qui utilise du code sous GNU GPL pour le réinjecter dans du code proprio.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: motif fallacieux ?
Posté par Elfir3 . Évalué à 10.
C'est bel et bien illégal, même en France (premier lien trouvé). Ce ne peut être fait que pour des raisons d’interopérabilité avec un logiciel indépendant.
Je trouve justement les éléments avancés dans le document comme très limite pour considérer qu'il s'agit d'une copie. Quand on doit correspondre à une interface, utiliser l'API du logiciel pour lequel on crée le plugin et que le scope de ces méthodes est très limité, on se retrouve très rapidement avec du code similaire. Pareil pour la configuration.
Maintenant, je ne connais pas le droit Américain, je suppose qu'ils ne sont pas obligés d'exposer l'entièreté des griefs dans le document et qu'ils ont gardé le plus croustillant pour le procès, mais dans le cas contraire, j'ai l'impression que beaucoup de logiciels ont décompilé leurs plugins.
# Alternatives
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 21 septembre 2019 à 13:13.
Quels sont les alternatives à Elastic Stack?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Alternatives
Posté par barmic 🦦 . Évalué à 7. Dernière modification le 21 septembre 2019 à 13:53.
Ça dépend de ce que tu fais.
Si tu t'intéresse à ELK (Elasticsearch Logstash Kibana) pour manager tes logs, il y a pas mal d'alternatives comme graylog, grafana ou chronograf. Je ne parle là que des solutions libres tu a des alternatives non libres comme splunk, dynatrace ou new relic qui sont très connues.
Si tu cherche à avoir un moteur d'indexe pour faire des recherches fulltext, tu as apache solr. Comme elasticsearch c'est basé sur la bibliothèque lucene. Je ne sais pas ce que vaut lucene face à elasticsearch.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Alternatives
Posté par flan (site web personnel) . Évalué à 3.
Grafana dessine des courbes et est plutôt complémentaire, quant à Graylog, il utilise ElasticSearch comme stockage.
[^] # Re: Alternatives
Posté par barmic 🦦 . Évalué à 4.
Grafana peut très bien le faire avec loki.
Pour graylog, tu as raison c'est un oubli de ma par.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Alternatives
Posté par flan (site web personnel) . Évalué à 2.
Je ne connaissais pas Loki. Est-ce que ça fonctionne vraiment bien, autrement dit, peut-on faire autant qu'avec Graylog ou Kibana en termes d'analyse de logs, de Dashboard ou d'alertes ?
[^] # Re: Alternatives
Posté par barmic 🦦 . Évalué à 1.
Je te l'ai jamais utilisé en production je ne saurais pas te dire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Alternatives
Posté par Paf . É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: Alternatives
Posté par Anonyme . Évalué à 3. Dernière modification le 22 septembre 2019 à 15:54.
Je crois qu'il n'y a jamais eu de clustering dans influxdb. Pour ça, ils avaient implémenté infludb-relay puis ils l'ont abandonné quand la fonctionnalité est devenu payante (Vente Privé/“We Pee” maintient un fork).
Par contre la stack TICK est libre : open core ne veut pas dire non libre.
[^] # Re: Alternatives
Posté par Paf . É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: Alternatives
Posté par barmic 🦦 . Évalué à 5.
J'allais te dire que pour ça il y a les fondations comme Apache ou Eclipse qui sont là pour établir un standard de projet.
On entends régulièrement que ce sont des cimetières de projets abandonnés, mais pour Apache, si tout projet peut rejoindre l'incubateur, seul les projets qui ont certaines propriétés peuvent en sortir. On peut retrouver tout ce qui est « Apache Way » dans le projet incubator. Outre la crainte d'une entreprise non libre, Apache donne un cadre pour éviter les batailles de gouvernance. Ça évite à chaque projet de définir des documents comme la constitution Debian pour s'organiser.
Ils imposent une forme de gouvernance, elle ne plaît pas forcément à tout le monde ou a tous les projets, mais ça permet de savoir que lorsqu'il y a Apache dans le nom d'un logiciel on sait comment il est fait1.
ça va assez loin parce que la fondation peut reprocher de ne pas assez communiquer sur un logiciel avec Apache. Par exemple si tu es une entreprise qui travaille sur « Apache SpamAssassin », il faut que ta communication explicite bien « Apache SpamAssassin » pour que ça ne puisse devenir de la pub déguisée pour ta version propriétaire « Better SpamAssassin » que tu vend de ton coté. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Alternatives
Posté par Paf . É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 devnewton 🍺 (site web personnel) . Évalué à 6.
La stack TICK c'est l'attac?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Alternatives
Posté par j_m . Évalué à 4.
Lucene ne gère pas la distribution des données ou des calculs, c'est elasticsearch ou solr qui s'en charge.
Donc si tu veux travailler sur de la recherche fulltext tu n'utilises pas lucene directement sauf si tu connais assez bien tes besoins en calculs distribués et que tu veux réécrire cette couche toi même.
[^] # Re: Alternatives
Posté par barmic 🦦 . Évalué à 5.
Dans ma dernière phrase il fallait lire solr et pas lucene.
Mais lucene est tout à fait utilisable tel que selon les besoins que tu as. Si ton besoin d'indexation est simple, ça peut valoir le coup de ne pas avoir à déployer un cluster solr/es. Tu n'a pas toujours besoin que ton index soit mis à jour en temps réel (pleins d'utilisateurs d'ES ne sont déjà pas temps réel) et si ton index n'explose pas (par exemple tu veux un index par utilisateur avec des quantités de données soumis à quotas), ça peut très bien le faire.
Par contre es est tellement simple à mettre en place et bien documenté que généralement ça n'a pas de sens de ne pas s'en servir (et il ne te limitera pas dans tes usages futurs).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Alternatives
Posté par Fulgrim . Évalué à 2.
Une alternative méconnue (car libérée récemment) est Vespa (vespa.ai). Le language de requetage est moins riche qu'elasticsearch, mais les performances sont excellentes et les possibilités concernant le tri des résultats sont vraiment très larges.
[^] # Re: Alternatives
Posté par kna . Évalué à -1. Dernière modification le 21 septembre 2019 à 18:04.
Il y a bien splunk mais c'est encore moins libre (et c'est pas gratuit non plus).
EDIT: mentionné avant, vous pouvez moinsser…
[^] # Re: Alternatives
Posté par romrom . Évalué à 4.
Sinon comme moteur de recherche fulltext, j'utilise xapian sur un projet en cours et j'en suis plutôt satisfait.
Rapide, en C++ (avec des bindings python), relativement bien documenté et complètement open-source (GPL).
# GitHub
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Ce qui m'ennuie le plus dans tout ça, ce n'est pas qu'une boîte s'attaque à ce que fait une autre sous des motifs peut-être fallacieux. C'est choquant si vous voulez, mais pas du tout inhabituel.
Là où ça devient amusant, c'est que sans cette centralisation sur GitHub, il ne se serait rien passé du tout, enfin, peut-être un procès, mais pour les utilisateurs, rien du tout. Sauf que là, on a une dépendance à GitHub, et il ne faut pas grand chose pour les convaincre de fermer un dépôt. C'est amusant, tous ces problèmes, quand on les observe de l'extérieur.
[^] # Re: GitHub
Posté par barmic 🦦 . Évalué à 7. Dernière modification le 23 septembre 2019 à 10:54.
Je doute que ce soit la difficulté technique de répliquer le dépôt qui les gêne.
Aujourd'hui les utilisateurs de SearchGuard ne sont techniquement pas impactés. Le site officiel est toujours là, tu peux toujours télécharger la version que tu souhaite sans difficulté. Les utilisateurs qui ne se renseignent pas ne savent même pas qu'il y a un litige.
Ce qui fait fuir les utilisateurs aujourd'hui, c'est la crainte du procès.
Pour ce qui est des développeurs :
Quant à la décision de github, elle est discutable, mais pas forcément choquante. Personne ne s'est pleins quand ils ont détruit le dépôt de deep-nude par exemple. Ils se donnent un droit de regard sur les dépôts, ils ne veulent pas prendre de risque.
il n'existe à ma connaissance pas aujourd'hui de plateforme d'hébergement de code acentré/fédéré/décentralisé qui ai suffisamment de popularité pour concurrencer github ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: GitHub
Posté par c2462250 . Évalué à 1.
Github s'autorise à fermer ce qu'il veur, comme Google avec le store Android. C'est le risque d'avoir des entreprises privées en situation de quasi monopole.
[^] # Re: GitHub
Posté par barmic 🦦 . Évalué à 3.
Bof… Framasoft s'autorise tout autant à supprimer du contenu. Le spectre de la loi est toujours le même. On avait un contributeur framasoft qui l'expliquait clairement ici même.1
C'est génial cette croyance qu'ils faut appliquer les décisions de justices avant que celles-ci soient prononcée…
Et la réforme du droit d'auteur européen semble malheureusement leur donner raison en demander à faire des vérifications à priori…
Bref je vois pas ce que l'« entreprise privée » ou le monopole changent quelque chose à ça.
pour vérification on peut trouver les cgu de framagit ici https://framasoft.org/fr/cgu/ ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: GitHub
Posté par Donk . Évalué à 3.
Chérie ça va couper
https://framablog.org/2019/09/24/deframasoftisons-internet/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.