[Proposition] Moteur de recherche libre

Salut,

Je reporte ici, pour plus de visibilité, une proposition que j’ai faite en réponse à cette demande.

Comme moteur de recherche libre, il existe searx, choisi pour Framabee, mais ce n’est en fait qu’un méta-moteur, qui semble avoir des difficultés parfois (souvent ?) à récupérer les résultats de Google qui, très probablement, voit d’un mauvais œil son travail détourné par d’autres ! Et puis, est-ce vraiment “dégoogliser” et être libre et autonome que de simplement récupérer les résultats de google, bing et autres moteurs des GAFAM en évitant l’aspiration de la vie privée ? C’est déjà beaucoup, mais on devrait pouvoir faire mieux !

Yacy semblait un excellent projet, mais semble être de plus en plus délaissé, apparemment à cause de deux défauts qu’on lui reproche :

  1. Le manque de peers, lui-même dû au manque de visibilité du projet, entraînant une indexation insuffisante et donc des sites oubliés ou insuffisamment mis en avant.
  2. Le fait qu’il soit écrit en Java, ce qui le rend inévitablement lent et gourmand en ressources.

Pour le premier point, le succès des alternatives proposées par Framasoft me laisse penser que s’ils voulaient promouvoir Yacy, le nombre de peers pourrait assez vite augmenter et cette excellente alternative à Google devenir de plus en plus performante grâce à cette augmentation.

Pour le second point, je pense qu’il faudrait ré-écrire Yacy en C/C++. Je n’ai pas encore regardé le code, mais à priori il ne devrait pas y avoir de grosses difficultés à retranscrire du java en C/C++. Il faut juste du temps, et je conçois bien que Framasoft ait d’autres priorités !

N’ayant pas regardé le code, même pas combien de lignes ça représente, je ne m’engage à rien, mais à priori ça m’intéresserait de retranscrire Yacy si je ne me sens pas trop seul. Il faudrait juste qu’il y ait un peu de monde pour tester et me soutenir moralement, et que si le résultat est correct je puisse compter sur Framasoft pour promouvoir le produit. Est-ce envisageable ?

PS : Au fait, merci à @come_744 pour son soutien et sa proposition :slight_smile:

5 « J'aime »

Bonjour agecanonix,
Je trouve l’idée bonne et j’espère qu’elle aboutira.

3 « J'aime »

Salut,

Merci pour ton encouragement, Thatoo :slight_smile:

J’ai quelques trucs à finir avant de regarder ça de plus près, mais j’ai assez bon espoir à priori d’arriver à convertir au moins les fonctionnalités les plus importantes de manière à ce que, le C étant très économe en ressources, elles deviennent vraiment performantes et que ce moteur vraiment libre et autonome puisse être utilisé dans de bonnes conditions et fournisse de bons résultats.

J’essaierai de tenir compte des avancées ici.

Hello !

J’entrevois une autre difficulté dans mon domaine de compétence : la communication.

Comment expliquer l’importance de faire du pair à pair pour un moteur de recherche, alors que j’en ai des très bien qui plantent des z’arbres, offrent des gouttes d’eau aux assos, ou sont une réussite Française qui fait de la pub pour la vie privée sur M6…?

Expliquer les principes de fédération à l’époque de l’internet des plateformes est un défi, et nous (Framasoft) constatons qu’on est tombé·e·s dans plusieurs écueils (et on apprend donc désormais on va tenter de les éviter).

Expliquer ce que va apporter le pair à pair, alors qu’au départ on aura forcément des requêtes plus lentes et des résultats moins bons, et quand ça demande des ressources et réflexes différents (par exemple en utilisation mobile avec forfaits data limités), c’est un défi en plusieurs temps.

À mon sens, il faut identifier, aux différentes étapes de croissance du projets, les publics qui sauront devenir partenaires et du coups quelles sont leurs attentes et comment un tel yacy reborn pourrait y répondre.

Je sais qu’on peut me dire “non mais on code d’abord et la stratégie on verra après”, et si ça permet de pas perdre une belle énergie et une belle dynamique comme tu l’as ici, @agecanonix, alors je suis d’accord et surtout : GO !

Cependant, commencer à imaginer cette conquête des cœurs des gens, en plusieurs étapes et avec plusieurs cercles, ça peut aussi permettre de se poser la question des usages, du dessein de ce code, et donc de mieux en réfléchir et l’ergonomie et les fonctionnalités dès la refonte.

Bref : suivant la taille de l’équipe qui se monterait sur cette belle proposition, j’espère que cet angle de réflexion pourrait vous être un outil constructif :slight_smile:.

De quelque manière que ce soit, je vous envoie tout mon courage et tout mes vœux de réussite, car c’est un besoin fort auquel vous vous attaquez là !

3 « J'aime »

Salut @pouhiou,

Merci beaucoup pour ton message et tes pistes de réflexion très intéressantes. Comme tu l’as déjà remarqué et expérimenté, les codeurs sont généralement peu enclins à s’en préoccuper, souvent par ignorance ou incompétence. Et puis, c’est ton boulot et pas le nôtre :wink: « Chacun son métier, et les vaches seront bien gardées » ! Nous sommes complémentaires, il faut que nous parvenions à communiquer, puis à nous comprendre, enfin à travailler ensemble. Je pense que tu as une assez bonne expérience en ce domaine, moi certainement moins, mais on devrait bien y arriver !

Comment expliquer l’importance de faire du pair à pair pour un moteur de recherche, alors que j’en ai des très bien qui plantent des z’arbres, offrent des gouttes d’eau aux assos, ou sont une réussite Française qui fait de la pub pour la vie privée sur M6…?

Ben ça, c’est ton boulot, le mien va être de traduire System.out.println(« Hello, World »); en langage C :stuck_out_tongue: Mais bon, c’est vrai que c’est une question dont on doit débattre tous les deux : je peux te donner des pistes, connaissant entre autres les raisons du demi-echec du code java et ce qu’un code C peut apporter, et toi tu peux me dire ce qui peut « se vendre » et ce qui est quasiment perdu d’avance.

Pour moi, tous ces moteurs ont de réels avantages par rapport à ceux des GAFAM. Mais à part Qwant et sauf s’il y en a d’autres du genre que je ne connais pas, ils ont tous l’inconvénient d’être des métamoteurs (ce qui serait un avantage sans ce qui suit) qui ne font que reprendre les résultats des principaux moteurs, et donc ils ne sont pas vraiment libres. C’est un peu comme si je cultivais moi-même mes légumes, mais que je me procure les graines chez Monsanto ! Il est certes plus long, plus difficile, moins rentable de trouver de bonnes graines traditionnelles, de variétés non trafiquées et beaucoup plus riches en nutriments, vitamines et autres oligo-éléments, mais au final c’est quand même bien plus sain et libérateur. « Vendre » ce genre de démarche n’est pas mon boulot et je ne sais pas faire du tout… C’est là que je compte sur des gens compétents en ce domaine :wink:

Une autre chose que je ne voudrais pas trop mettre en avant tant que je n’ai pas mieux étudié la question, c’est la possibilité d’améliorer les résultats de Yacy en récupérant au plus vite, grâce à ActivityPub, les nouvelles publications comme les vidéos sur PeerTube entre autres. Si ça s’avère possible, on devrait facilement être meilleurs que GG sur toutes ces publications, et donc au moins lui être bien complémentaire. J’envisage même - toujours sous réserve d’avoir mieux étudié la question - de coupler ce moteur à un gestionnaire de favoris ou de l’utiliser comme tel, ce qui en plus du côté pratique devrait participer à un enrichissement plus rapide des résultats.

Enfin, un outil de recherche libre et ouvert depuis l’indexation du web jusqu’à l’affichage des résultats me semble quelque chose d’indispensable : tant qu’on aura ne serait-ce qu’un tout petit morceau géré de manière non libre, on restera soumis à une dépendance et donc à un contrôle inacceptables.

Expliquer ce que va apporter le pair à pair, alors qu’au départ on aura forcément des requêtes plus lentes et des résultats moins bons, et quand ça demande des ressources et réflexes différents (par exemple en utilisation mobile avec forfaits data limités), c’est un défi en plusieurs temps.

Pour le premier point, je dirais simplement que la liberté a un prix et que c’est à chacun de voir s’il veut le payer ou devenir un esclave panurgiste. Le prix de la liberté en matière de moteur de recherche, c’est d’en avoir plusieurs pour jouer sur la complémentarité et éventuellement d’accepter un peu plus de lenteur. Quoique… La lenteur est ce qu’on reproche actuellement à Yacy, mais il est écrit en Java. Ré-écrit en C, il sera forcément bien plus rapide. Bon, ce qui est moins clair, c’est le temps passé aux communications entre pairs, mais c’est quelque chose qui devrait rapidement évoluer (bien plus vite que ne le fait PeerTube, puisque les pairs sont des serveurs toujours prêts à répondre, pas des particuliers qui regardent la même vidéo en même temps, donc nécessairement peu nombreux).

Pour le second point (mobiles avec forfait data limités), je dirais que c’est un point important à ne pas oublier, et que je n’y avais effectivement pas pensé. Mais à priori, je pense qu’il y a deux approches complémentaires :

  1. Peut-être y a-t-il de la communication à faire sur l’effet mode de la téléphonie mobile et une réflexion sur ce qu’on veut comme informatique et comme Internet. Ce que j’ai vu de mieux jusque là, c’est cette conf aux JDLL. Si le mobile est un outil extrêmement pratique, il n’est pas nécessaire dans bien des cas, alors que les pratiques et le discours ambiant nous laissent croire qu’il l’est (je n’en ai pas, et n’en ai aucun besoin ni envie !). Il y a certaines choses qu’il vaut mieux faire avec une bonne connexion Internet, il y en a qui sont même impossibles sans ça. Pas que du P2P pour un moteur de recherche ! Et je ne parle pas de surveillance, bridage, censure…
  2. Il faut certainement prévoir la possibilité d’être simple client, c’est à dire pouvoir disposer d’une simple interface de recherche, située sur un pair Yacy distant (par exemple chez un CHATON) et qui se charge de retransmettre les résultats obtenus. Le forfait ne devrait dans ce cas pas être utilisé plus qu’avec Framabee ou GG.

Cependant, commencer à imaginer cette conquête des cœurs des gens, en plusieurs étapes et avec plusieurs cercles, ça peut aussi permettre de se poser la question des usages, du dessein de ce code, et donc de mieux en réfléchir et l’ergonomie et les fonctionnalités dès la refonte.

Oui, tout à fait d’accord, bien sûr ! Sauf une petite nuance : si j’envisage de convertir le java en C, à priori il ne devrait pas y avoir de fonctionnalités différentes. Bon, ça contredit ce que je mentionnais plus haut et certes, j’aimerais bien autant que possible améliorer tout ce qui peut l’être. Sauf que le mieux est l’ennemi du bien et qu’on risque rapidement de faire un fork aux fonctionnalités très différentes (ce dont je suis loin d’être sûr d’être capable) et donc un développement très long, au lieu d’une simple retranscription qui devrait (du moins j’espère !) être bien plus rapide.

Le but, dans un premier temps au moins, est de pallier aux principaux défauts de Yacy : lenteur, qui entraîne une sous-utilisation, qui empêche un apprentissage correct et donc de bons résultats., et aussi l’utilisation de Java qui pose des problèmes d’incompatibilités de versions.

Après, c’est vrai qu’il ne faudra pas négliger la communication pour ne pas passer à côté de certaines adaptations voire améliorations relativement faciles à implémenter pendant les inévitables réadaptations à faire lors de cette transcription. J’ai pensé à certaines, mentionnées plus haut, mais d’autres ont peut-être des idées intéressantes à garder à l’esprit pendant ce travail.

De quelque manière que ce soit, je vous envoie tout mon courage et tout mes vœux de réussite

Merci :slight_smile: Avec un tel intérêt et de tels encouragements, ça ne risquera déjà pas de foirer au niveau motivation !

1 « J'aime »

Bonjour,

J’aimerai éviter de me faire l’avocat du diable, mais je tiens à éviter que l’on perde de l’éerngie pour pas grand chose :o)

1er point :

Ici, je n’ai pas l’impression qu’une analyse en profondeur ait été faite. Que reproche-t-on au moteur de recherche de Google ? Plutôt pas grand chose, il est efficace et remonte rapidement des résultats cohérents.
Que reproche-t-on à Google ? C’est là qu’il y a un souci :

  • ils utilisent leur moteur (et autres applis) pour surveiller les gens et en tirer un maximum d’informations pour pouvoir vendre de la publicité
  • ils enferment l’utilisateur dans une « bulle » permettant ainsi de renvoyer plus vite les réponses attendues à ce dernier

L’utilisation de méta-moteurs permet de plus ou moins contrebalancer ces 2 points négatifs :

  • l’utilisateur est perdu dans une foule d’autres, le moteur de recherche ne peut plus l’espionner de manière efficace
  • l’utilisateur étant dans une foule, la bulle est moins restrictive « a priori »

Enfin, ta dernière phrase : « on devrait pouvoir faire mieux ! » me semble vraiment trop enthousiaste. Comment peut-on espérer faire mieux étant donné que cette société paye des experts et a, à sa portée, une masse d’argent colossale ? Pour cela, il faudrait permettre d’avoir des choses intéressantes pour les gens. C’est ce qu’a réussi à faire peertube par rapport à youtube en déportant les besoins matériels entre les instances et les spectateurs. Avec un moteur de recherche, c’est p’tet un peu plus compliqué…

Yacy est parti sur un bon modèle théorique je pense, mais il manque en effet de visibilité et de pairs. De plus, peut-être que de voir plusieurs fois la même requête arriver (« bébé angleterre », « coupe du monde 2018 », etc…), il pourrait stocker sur tous les noeuds les résultats des requêtes les plus demandées permettant ainsi d’y répondre plus vite et sans accès réseau.

Ce qui nous amène au 2nd point :

  1. En effet, Yacy est peu visible, connu. Je pense que l’idée de départ est bonne, mais qu’il manque de contributeurs de tous horizons (design, code, tests, etc…)

  2. Grosse bêtise, voire très grosse bêtise. Yacy fonctionne sur un principe simple :
    premièrement il collecte des données (parcours des pages et indexation), et cela se fait en tâche de fond. C’est p’tet lent, mais ce n’est pas son point faible, il donne des résultats corrects.
    deuxièmement, il présente les résultats via une application web. C’est cette application qui est potentiellement lente, et plus précisément les retours lors d’une recherche. Ceci est du aux appels réseaux aux différentes paires et pas du tout au langage utilisé pour cela. Les appels réseaux ralentissent énormément les retours (qu’il faut traiter, alors qu’ils ne contiennent peut être rien de très intéressant, etc…).

Bref, je pense qu’une bonne idée serait effectivement de se pencher sur le code source de Yacy, puis d’aider le(s) développeu-r-se-s à l’améliorer, mais juste le transcrire en C/C++ me semble être de l’énergie perdue… Trop de projets informatiques subissent ce sort du « on refait tout depuis zéro, ça sera plus propre ».

1 « J'aime »

Salut,

Merci de te préoccuper ainsi de la bonne gestion de mon énergie, mais ça aurait été sympa de ne pas déformer mes propos en les sortant de leur contexte et de ne pas qualifier mon analyse de grosse bêtise en donnant des arguments si vaseux !

Pour ton premier point, tu cites toi-même ma phrase démontrant que le « on devrait pouvoir faire mieux » ne se rapportait pas du tout à la qualité du moteur de recherche de GG, mais bien à la fausse autonomie et l’illusion de liberté que procure l’utilisation d’un méta-moteur.

J’ai effectivement eu l’audace, un peu plus loin dans mon post, d’affirmer que certaines améliorations de yacy pourraient l’amener à être meilleur que GG sur un point bien précis : l’indexation quasi immédiate des vidéos Peertube et autres publications signalées par ActivityPub. Non que je mette en doute les capacités de GG à le faire, mais parce qu’il paraît assez évident qu’il n’a aucun intérêt à le faire.

Remarquons au passage que cela implique un autre point sur lequel Yacy peut être bien meilleur que GG, et qu’aucun méta moteur ne pourra compenser : la neutralité des résultats.

Pour ce qui est de ma « grosse bêtise », tu dis :

cela se fait en tâche de fond. C’est p’tet lent, mais ce n’est pas son point faible, il donne des résultats corrects.

Ce n’est pas parce qu’une tâche de fond n’a rien de visible qu’elle ne consomme pas de ressources ! Et c’est justement cette consommation de ressources qui a fait fuir plusieurs utilisateurs de Yacy. Or, les logiciels codés en C, quels qu’ils soient, figurent parmi les moins gourmands en ressources, alors que ceux en Java en consomment énormément.

Les appels réseaux ralentissent énormément les retours (qu’il faut traiter, alors qu’ils ne contiennent peut être rien de très intéressant, etc…).

Ben oui ! Les échanges nécessaires via le réseau, on est bien d’accord que changer de langage n’y apportera aucune rapidité supplémentaire. Mais ces échanges ont fait leurs preuves, entre autres dans bittorrent et dans Peertube. Ce qui coince dans Yacy, c’est leur traitement. Et pour ça, le choix du langage influe directement sur la rapidité d’exécution.

juste le transcrire en C/C++ me semble être de l’énergie perdue… Trop de projets informatiques subissent ce sort du “on refait tout depuis zéro, ça sera plus propre”.

Encore un propos contradictoire et des propos que tu me prêtes alors que ce n’est pas du tout ce que j’ai dit ! Je ne refais pas tout depuis zéro, puisque je transcris en C/C++ ! Et si je n’ai pas parlé de le faire avec les devs de Yacy, c’est parce que je ne veux pas m’avancer sur une éventuelle collaboration avant de voir avec les intéressés. Dans un premier temps, je compte me contenter de retranscrire, en collaboration ou non peu importe. S’ils n’ont pas écrit en C, c’est probablement qu’ils ne connaissent pas ou pas assez, et à part m’aider à comprendre certaines parties ardues du code, ils ne pourront pas beaucoup m’aider. Mais pour la suite, je compte bien que nous puissions étudier ensemble comment améliorer Yacy, même si on maintient une version java et une version C. Il y a parfois des dépenses d’énergie en apparence inutiles qui permettent malgré tout aux choses d’avancer mieux et plus vite.

Enfin, pour finir, je voudrais mentionner un point que je n’ai pas évoqué ici : Yacy est actuellement impossible à installer sur Debian (et certainement pas que) à cause d’un problème de version d’OpenJdk. Apparemment, ça avait été résolu, mais la version Debian ayant à nouveau changé depuis, il y a des chances que ça ne fonctionne de nouveau plus. Pour pallier à ce genre de problème, soit on met une équipe suffisante pour courir après les changements de version et refondre le code à chaque fois, soit on opte pour une solution plus stable, et donc sur un langage qui ne repose pas sur des sables mouvants !

Je n’ai parlé de bêtise que lorsque tu as comparé le java au C. Une étude récente pour appuyer mes propos : Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

On voit qu’en terme de temps de calcul le Java est assez proche du C (les VM ont pas mal évoluées ces dernières années) et donc je redis que je ne pense pas qu’il s’agisse d’un problème de langage.

Je vois aussi plus de 350 bugs en attente de résolution sur leur Mantis : http://mantis.tokeek.de/view_all_bug_page.php dont moins de 10 bugs sur les 2 dernières années, ce qui semble montrer que la communauté semble s’être effritée ce que tu relèves parfaitement dans ton analyse ;o)

Enfin, un test avec le mot clef « fakir » sur http://yacy.searchlab.eu ne répond qu’au bout de 20 secondes, ce qui me fait dire que la recherche est lancée en fond et attend la réponse des autres pairs, ce qui me semble beaucoup plus optimisable que de simplement changer de langage.

Voilà, voilà, maintenant je ne te reproche en rien ton idée, j’essaye juste de tenter de canaliseer ton enthousiasme vers ce qui me semble rapporter plus à toute la communauté ;o)

Salut,

J’ai lu en diagonale ton “étude”. Si on s’en tient à ce qui y est indiqué, passer du java au C présente des avantages certains, même s’ils sont très inférieurs à ce que j’aurais cru.

Mais surtout, s’arrêter à une étude, même si elle semble menée sérieusement, c’est aller un peu vite en besogne.

Déjà, s’il y a plusieurs langages, c’est qu’il y a des besoins différents. Et donc, un langage quel qu’il soit sera toujours bien meilleur dans “son” domaine que dans d’autres. Ce serait un peu comme comparer le vélo, la voiture, le train et l’avion ! Il faut bien avoir de drôles d’idées pour comparer PHP et Javascript !

D’autre part, comment les comparer valablement ? Si on fait le même programme qu’on transcrit de l’un à l’autre, quelles que soient les précautions qu’on prenne, on avantage nécessairement certains langages plus adaptés à cette manière de faire. Et si on fait écrire séparément et indépendamment par des spécialistes de chaque langage, on ne compare plus vraiment la même chose.

Sans mettre en doute le sérieux avec cette étude a été menée, il est inévitable donc que les résultats soient biaisés. Et en l’occurence, cela donne à Java un avantage qu’il n’a pas dans des conditions normales d’utilisation. Wollin, dans le dernier commentaire, s’étonne des piètres résultats de Fortran. Pour avoir pratiqué moi aussi ce langage, je suis aussi surpris : Sauf dans des conditions particulières où peut-être que Java prend l’avantage, dans le domaine qui est le sien et d’après ma propre expérience, Fortran ne donne aucune impression de lenteur comparé à C (J’ai expérimenté ça sur des modules de calcul thermique qui avaient justement besoin d’une grande rapidité. FORmula TRANslator porte bien son nom : facilité de programmation pour ce genre d’application, et efficacité lors de l’exécution !).

De plus, cette étude se cantonne à 3 critères, importants, certes, mais qui ne sont pas les seuls à devoir être pris en considération. J’en ai cité un autre dans mon post précédent : la stabilité de tout ce qui va avec, et donc entre autres de la VM pour Java. Il y a aussi les compétences des développeurs : il vaut souvent mieux qu’ils travaillent avec un langage qu’ils maîtrisent parfaitement qu’avec un qu’ils connaissent mal, même s’il est plus performant.

Bref, se baser sur une étude de rapidité et d’écologie pour choisir un langage n’est pas la bonne approche, et dans le cas qui nous intéresse, il faut gagner en rapidité, en simplicité d’installation et en stabilité, alors que la portabilité, principal avantage de Java, ne nous intéresse pas (je vois assez mal un Windowsien vouloir à tout prix se passer de GG ! Et donc on ne perd pas grand chose à mon avis de laisser tomber le monde MicroSoft alors qu’on se traîne un boulet en voulant les garder : la production, les tests, la distribution et l’entretien d’une version Windows demande pas mal d’énergie et de mauvais compromis). Donc, tout pousse à choisir un langage très proche du système et à se contenter d’une compatibilité POSIX, plutôt qu’essayer d’améliorer l’existant qui restera toujours moins (je maintiens que c’est même beaucoup moins) rapide, plus compliqué à installer et moins stable.

Et puis, il y a aussi un point incontournable à prendre en compte : si je touche au code de Yacy, ce ne sera pas pour écrire du Java. Je ne sais pas faire et n’ai aucune envie d’apprendre, en plus d’être très intimement convaincu que Java est un très mauvais choix pour ce projet. Si l’équipe actuelle ou de nouveaux devs veulent continuer d’améliorer Yacy en Java, qu’ils le fassent ! Dans la mesure de mes possibilités, je reprendrai leurs améliorations pour les transcrire ou les ré-écrire en C mais par choix et par manque de compétences, je ne travaillerai jamais en Java.

Bonjour,
Cet avis / questionnement peut sembler prématuré, mais ces questions m’ont l’air importantes, tant pour le logiciel lui-même que pour la communication autour.

Des avantages de Yacy

C’est un peu le même raisonnement que celui d’@agecanonix qui me donne envie de contribuer à Yacy :
Les géants américains qui indexent Internet ne respectent pas la vie privée. S’il existe des méta-moteurs de recherche ayant ce but de respecter la vie privée, ils sont encore dépendants des GAFAM. Yacy permettrait que les données d’indexation soient libres de droits et partagées, permettant un référencement d’Internet indépendant des GAFAM, et cette indépendance en termes de puissance de calcul n’est permise que grâce au P2P.

Cependant, il ne s’agit pas là de donner des gouttes à des projets humanitaires, cela est vrai. C’est un objectif différent.
(J’avoue que jusque là j’utilise plutôt Lilo que Qwant sur mon ordinateur.)

Quant à Qwant, qui est un cas à part, il suffit de lire la presse récente pour voir qu’ils font finalement appel à Microsoft pour avoir une puissance de calcul répondant à leurs attentes et ne sont donc pas totalement indépendants. Dommage…

Du changement de langage

J’espère que le C/C++ permettra de rassembler un plus grand nombre de développeurs parce que moi non plus, le Java, même en y ayant touché, je n’aime pas ça. (C’était un moyen simple et rapide d’utiliser un port CDC, d’avoir une interface graphique et de faire des émulations clavier.)
En plus, les versions de Java, je trouve que c’est la galère.

Donc si Java a des avantages incontestables pour développer rapidement, il ne me plaît pas du tout sur du long terme.

Des modifications

@agecanonix, tu parles de modifications en t’excusant de t’avancer, mais je pense que tu as raison d’en parler, parce qu’une traduction ne suffirait pas à mon sens à attirer des utilisateurs (mais des contributeurs, peut-être).
Il y a là un profond travail sur ce que l’on veut faire, et c’est fortement lié à la communication. (Merci @pouhiou pour tes éclairements)

Pour ce qui est de l’ordre des choses, pour l’instant rien n’a commencé au niveau du développement à ma connaissance.
Si je comprends bien, deux options s’offrent à nous :

  • Soit on traduit tout avant de modifier, auquel cas on peut faire un travail de réflexion et un travail de traduction en parallèle. À la fin de cette première étape Yacy est fonctionnel comme une exacte duplication de la version Java. Les modifications commencent après cette première étape.
  • Soit on réfléchit à ce que l’on veut apporter à Yacy avant de traduire, on économiserait alors la traduction de quelques fichiers (je pense notamment à l’interface de recherche), mais ce cas me semble plus dangereux à cause du risque de se fixer des objectifs trop hauts bloquant le projet en retardant une première version utilisable. Ce risque n’existe peut-être pas : seuls des développeurs, ce que je ne suis pas, pourront en juger.

En ce qui concerne la proposision de @agecanonix sur ActivityPub, ça serait génial, d’autant plus qu’il manque probablement un moteur de recherche au Fediverse (il faudra bien respecter la volonté de Mastodon (ici par exemple) de ne faire une recherche que sur les hashtag), mais chaque chose en son temps, je suis d’accord.
En restant dans le domaine de l’amélioration des résultats, je pense il ne faut pas rêver pour ce qui est des recherches généralistes. Cependant, il ne faut pas oublier que la décentralisation permet la spécialisation : un groupe de fans ou de professionnels d’un domaine pourrait travailler au référencement des sites spécialisés dans ce domaine de manière approfondie.

Alors un enjeu considérable, et qui m’inquiète un peu, est la séparation des tâches.

De la séparation des tâches

Il y a déjà des questionnements sur la consommation de bande passante. De ce que j’ai compris, il y a toujours une architecture avec des clients et des serveurs, et ce sont les serveurs qui communiquent entre eux via P2P. Donc pour le client, la consommation de réseau ne serait pas supérieure à celle de Searx par exemple.

Ensuite, pour le travail du moteur de recherche, il y a plusieurs rôles si je comprends bien :

  • Le travail de fond : crawl, index ;
  • Le stockage de la base de données ;
  • L’interface utilisateur.
Le stockage

Je m’interroge notamment sur la question environnementale :

  • Si tout le monde stocke tout, il y a d’énormes redondances, ça occupe une place immense sur les serveurs, donc ça consomme.
  • Si chaque instance stocke une partie de la base, il faut que chaque instance appelle toutes les autres à chaque recheche. Non seulement c’est lent, comme l’écrit @mindiell, mais en plus ça consomme beaucoup.

Il serait probablement intéressant pour la communication :

  1. d’abord, de travailler sur la répartition des tâches entre les instances, notamment pour le stockage, pour la rendre le moins gourmande en énergie possible, et ensuite
  2. d’établir des iconographies pour expliquer la répartition des tâches (parce que je ne suis sûrement pas le seul à ne rien y comprendre) et en quoi les choix effectués limitent la consommation d’énergie.

Pour la répartition, toujours dans l’idée de spécialisation des instances, si on arrive à regrouper les données par catégories, on pourrait essayer de limiter les appels aux instances susceptibles d’avoir le résultat ? Je pense qu’il y a tout un travail de réflexion à faire ici.

Aurait-il du sens de faire un parallèle avec la méthode qu’emploie OSM pour stocker et livrer ses bases de données et ses tuiles ?

Les performances

Pour ce qui est des performances, pourrait-on envisager une option pour séparer (pas totalement, bien sûr) l’interface de recherche et le crawl/index ? C’est-à-dire avoir plus de machines qui font le travail de fond que d’instances qui offrent une interface de recherche ? Une machine pourrait alors travailler “au service” d’une – ou plusieurs – instance. (Il y a encore la question du stockage des bases de données permettant cela.)

Idées de moindre importance qui peuvent bien attendre

Pour la sémantique latente (j’ai lu que ça servait aux moteurs de recherche sur Wikipédia), est-ce qu’il serait envisageable de se baser sur le Wiktionnaire ou une autre base de données ouverte pour avoir des synonymes ?

Pourrait-on suivre les modifications de Wikipédia par exemple (ou de tout autre site ayant son propre moteur de recherche interne) pour avoir une copie à jour de son index de recherche et ainsi éviter d’avoir à recréer son index sans pour autant l’appeler à chaque fois qu’une recherche est effectuée comme le ferait un méta-moteur de recherche ?

1 « J'aime »

Salut,

Bravo et merci pour cette superbe analyse, @come_744 !

Si n’ai pas poussé très loin mes réflexions, c’est simplement qu’il me manque certaines bases :

  • Par manque de temps pour le moment, je n’ai pas tenté d’installer Yacy, ce qui semble maintenant assez problématique même si j’ai quelques pistes. Donc, je ne sais ce qu’il fait et comment il le fait que par ce que j’ai pu en lire, ce qui est nettement insuffisant pour juger de ce qu’il faudrait modifier et améliorer. Il n’y a qu’une chose flagrante : l’emploi de Java est un gros handicap dont il faut s’affranchir.
  • J’ignore comment peut fonctionner un moteur de recherche de ce type. D’où mon idée de repartir de Yacy qui semble une bonne base plutôt que de faire un autre moteur from scratch.

Donc, mon idée est bien de rendre Yacy plus facilement installable et plus rapide dans un premier temps, ce qui permettra ensuite de l’améliorer peu à peu. Comme tu le dis, @come_744, vouloir immédiatement apporter un tas de changements risque bien de bloquer le projet. Et comme dit plus haut, je ne m’en sens pas capable actuellement, donc la « traduction » serait en même temps un bon moyen d’étudier en profondeur le fonctionnement, phase indispensable avant les modifications.

Cela dit, ça m’est déjà arrivé de traduire ou adapter du code, je sais bien qu’en le faisant on en profite toujours pour faire quelques petites améliorations quand on juge que c’est possible et utile.

Il est donc bien d’avoir en tête tout ce qu’on pense utile de faire, surtout si on travaille à plusieurs pour bien se coordonner. Après, il faut quand même garder en tête que tant qu’on n’a pas étudié en profondeur le fonctionnement et le code, il n’est pas forcément judicieux de pousser trop loin les réflexions qui risquent de ne pas coller avec la réalité.

Séparation des tâches
J’ai lu quelque part qu’il avait été mise en place une instance permettant à qui voulait de faire une recherche sans installer toute l’artillerie lourde de crawling/indexing, mais que ça avait été abandonné parce que trop de gens « profitaient » de Yacy pour faire des recherches sans participer au crawling/indexing, et que c’est surtout cette tâche qui fonctionne d’autant mieux que les acteurs sont nombreux. Donc, avoir l’idée en tête, Ok, mais rester prudent sur la mise en oeuvre !

Le stockage
Je ne suis pas sûr que ce soit le plus gros problème, par contre celui de la tenue de la charge en est certainement un énorme ! Il faut que le serveur puisse répondre à des centaines (si on reste très modeste !) de requêtes simultanées.

Personnellement, je m’estime totalement incompétent pour estimer quoi que ce soit en ce domaine ! Donc : je traduis « bêtement » le code Yacy, et on voit à l’usage ce que ça donne et comment améliorer. Après, si d’autres pensent pouvoir faire une assez bonne pré-estimation pour orienter le codage dans un sens ou un autre, pourquoi pas ? Il faudra quand même arriver à me convaincre que c’est préférable à « ma » solution basée sur l’expérience préalable :wink:

Je ne sais pas si les besoins et solutions peuvent être considérés comme assez proches, mais si oui pourquoi pas ? Et de toutes manière, essayer de travailler de concert avec d’autres projets libres ne peut qu’être bénéfique d’une manière ou d’une autre.

Autres idées

Aucune idée de comment ça fonctionne ! J’aurais plutôt penché pour du machine learning, mais bon… En tous cas, l’idée de collaborer avec d’autres projets libres - surtout lorsqu’ils sont quelque chose d’intéressant et d’important à indexer - me plaît et me semble presque incontournable ! Par contre, c’est peut-être déjà fait dans Yacy, il faudrait voir le code d’abord…

Là aussi, c’est une idée à laquelle j’adhère totalement. Ce qui serait génial, c’est que Wikipédia se mette à balancer ça via Activity Pub :wink:

1 « J'aime »

Je vois que Java reste un truc infranchissable pour toi. Peux-tu me redire ce qui « lent » sur Yacy ? S’il s’agit du site de présentation et de recherche peut-être peux-tu commencer par traduire en C ce morceau là uniquement ?
Je veux dire que si l’indexation (qui est sans doute le plus gros morceau) est lente, elle semble, pour le moment, suffisante pour retourner des résultats corrects lors d’une recherche (il me semble).

Salut @Mindiell,

Bon, pour qu’on se comprenne bien, je re-situe les choses dans leur contexte. J’ai découvert Yacy il y a quelques années, mais pour diverses raisons purement personnelles (surbooking entre autres), je n’ai jamais été jusqu’à la phase de mise en service et tests. Et dernièrement, je me suis à nouveau penché sur ce moteur de recherche espérant bien cette fois-ci pouvoir l’installer. Et c’est là que le bât blesse : pas possible :frowning: Et en creusant un peu, je découvre que le projet est en totale perte de vitesse parce que ça n’a jamais donné les résultats escomptés. Les causes invoquées sont claires :

  1. beaucoup trop gourmand en ressources (une instance met à genoux tout serveur qui n’a pas une puissance de calcul et une mémoire confortables… et ça n’élimine pas que les Raspberry PI :frowning: )
  2. incessants problèmes de version de VM Java et de compatibilité avec différentes distribs
  3. Résultats très peu pertinents, raison invoquée : trop peu d’instances, donc pas assez de crawling/indexation
  4. lent

Comme tu vois, il n’y a pas que la lenteur qui coince ! Elle n’est même que peu mise en avant, contrairement aux autres problèmes qui sont invoqués par de nombreux anciens possesseurs d’une instance… ou volontaires pour en installer une mais qui ont dû abandonner faute d’avoir un serveur capable de tenir la charge.

Je n’ai pas été plus loin pour le moment : j’ai d’autres choses à finir, j’ai décidé de m’y consacrer d’abord tout en tâtant le terrain pour voir si des gens seraient prêts et suffisamment nombreux pour remettre en route, le moment venu, un pool de testeurs suffisant.

En effet, je pense qu’on peut très nettement améliorer l’existant simplement en changeant de langage et si on reprend les points ci-dessus :

  1. C est nettement moins gourmand en ressources que Java
  2. Pas de problèmes de version de VM avec C ! Et si on évite les bibliothèques exotiques, s’il y avait un problème de compatibilité de versions, une simple recompilation suffirait
  3. J’ai vu passer quelque part un nombre de plus de 600 instances opérationnelles. Malheureusement, je n’y ai pas prêté attention sur le coup. Mais on peut s’interroger pourquoi un tel nombre permet encore d’affirmer qu’il en faudrait beaucoup plus pour obtenir un bon crawling et donc des résultats pertinents. Il peut y avoir un tas de raisons, mais avec un code rapide et peu gourmand, on ne peut qu’améliorer les choses, probablement même de manière spectaculaire.
  4. Ben oui, je maintiens : même avec des benchmarks qui le mettent à son avantage, Java est plus lent que C. Je ne serais même pas surpris, pour Yacy, que la différence soit assez énorme.

Et j’ajouterais assez volontiers :
5. À part pour certaines fonctions, la POO ne sert pas à grand chose. Si on arrive à recoder les parties les plus sensibles en C et non en C++, on y gagnera encore beaucoup en ressources et surtout en vitesse.

Donc, voilà où j’en suis de mes réflexions. De toutes manières, Java a fait ses preuves : le projet est mort ou presque. Je ne sais pas si C pourra le ranimer, en tous cas l’expérience le prouve : cette ranimation passera par un changement de langage ou ne sera pas. Si ça avait été possible avec Java, ça aurait déjà été fait, puisque les problèmes sont bien identifiés.

Déjà, ce n’est pas ce que j’ai vu qu’en disent ceux qui ont testé suffisamment en profondeur. C’est d’ailleurs la raison de l’abandon pour plusieurs d’entre eux.
Ensuite, à supposer que cette indexation soit satisfaisante sur le plan de la pertinence des résultats, elle participe (à mon avis beaucoup, mais c’est une supposition presque gratuite) à la grande consommation de ressources et de mémoire, autre facteur d’abandon ou de non-installation couramment invoqué.
Enfin, le fait qu’elle soit lente oblige à beaucoup plus d’instances pour compenser, ce qui d’une part est un handicap au moins au début, d’autre part induit une multiplication des échanges réseau, que tu accusais d’être responsable d’une bonne part des lenteurs.

Et puis (est-ce volontaire ou non ?), ce que tu préconises va maintenir chacun des langages là où il est le moins efficace. On risque alors de ne démontrer que le fait que tu as raison : changer de langage apporte peu ! Pour (in)valider un concept, il faut un peu plus de rigueur !

Pour finir, que crois-tu que tu vas perdre si je réussis ? Au pire, si tu tiens à ton Java, tu pourras continuer à maintenir la version Java : j’ai tout intérêt, au moins pour commencer, à garder une compatibilité totale avec les instances en place, donc rien n’empêchera que tu en installes d’autres en Java elles aussi. Oui, je l’affirme, je déteste Java et son concept, mais pas au point d’empêcher ceux qui y croient de le pratiquer. Après, si les instances en C fonctionnent mieux que celles en Java, tant mieux : Yacy sera sauvé ! C’est ce qui compte. :wink:

2 « J'aime »

Ah, j’avoue, j’y gagnerais et pas que moi :o)
Personnellement, je déteste le langage Java, mais j’essaye de voir la masse de boulot dans laquelle tu t’engages et le (gros) risque de ne pas y arriver et de te voir perdre ton enthousiasme. Ca, ca serait un coup dur :confused:
Donc, bon, tu as répondu à mes interrogations, je te souhaite vraiment bon courage pour le projet et lorsque tu auras une première version utilisable, je pourrai faire partie des testeurs :wink:

2 « J'aime »

Salut @Mindiell,

:laughing: J’avoue que tu m’as bien eu ! Je te prenais pour un de ces inconditionnels de Java ou l’un de ceux que mentionne Confucius :

:man_with_gua_pi_mao: Confucius
Lorsque tu fais quelque chose, sache que tu auras contre toi, ceux qui voudraient faire la même chose, ceux qui voulaient le contraire, et l’immense majorité de ceux qui ne voulaient rien faire

Désolé de cette confusion, mais tu es trop bon acteur :wink:

Effectivement, c’est un risque. Mais qui ne risque rien n’a rien ! Il va déjà falloir que je trouve du temps : j’espérais pouvoir m’y mettre assez vite, mais pour diverses raisons j’ai pris du retard dans ce que je veux finir avant, et du coup je ne commencerai probablement que fin Juin si tout va bien. Mais bon, vu l’enthousiasme de @come_744, le soutien (prudent, mais c’est son rôle) de @pouhiou, de Thatoo et du tien, je n’ai plus qu’à me montrer à la hauteur !

Merci :smiley: Je tiendrai au courant ici et peut-être ailleurs si nécessaire pour une bonne coordination de ceux qui prendront une part active au projet.

En attendant, ceux qui le souhaitent peuvent toujours se proposer pour tester (on est encore trop peu nombreux, mais il faut peut-être une POC pour susciter des vocations !) voire pour donner un coup de main au code, graphisme (qui risque bien, pour cause des bibliothèques utilisées, d’être très différent de la version Java), traduction multilingue (y a-t-il des espérantistes ici ? J’aimerais bien faire une version espéranto, mais mes notions sont bien faibles) ou autre. Et bien sûr, plus j’aurai d’encouragements, moins je risquerai de perdre mon enthousiasme :wink:

2 « J'aime »

Bonjour !

Je viens de jeter un coup d’œil au code. Voici quelques petites remarques pour plus tard.

Solr

Il faudra sûrement trouver un équivalent de Solr en C/C++ ; sinon, le recoder. (Il y a sûrement d’autres biblis dans le même cas.)

net.yacy.cora.federate.FederateSearchManager

La fonction getBest n’utilise pas l’argument query demandé. J’ai l’impression que le critère principal de sélection soit le fait que l’on n’aie pas déjà contacté l’instance distante durant les 15 dernières secondes.
Donc c’est indépendant de la recherche effectuée, contrairement à ce qu’indique la documentation.

Cependant il semblerait que net.yacy.cora.federate.yacy.Distribution attribue aux pairs des poids sur des mots pour limiter les pairs appelés à chaque recherche.

Synonymes

Une gestion des synonymes est déjà prévue mais actuellement il n’y a “que” : Anglais, Allemand et Russe.

Au passage il y a une autre fonctionnalité (je n’ai pas bien compris de quoi il s’agit) qui n’est disponible qu’en Allemand.

net.yacy.cora.plugin.ClassProvider

Apparemment il y a une prise en charge d’extensions en fichiers *.jar. Alors naturellement les questions suivantes vont se poser :

  • Comment gérer une telle fonctionnalité en C/C++ ?
  • Y a-t-il beaucoup d’extensions ? Lesquelles sont à traduire ?

Wiki

Faut-il fournir (et donc traduire) un Wiki comme le fait YaCy actuellement ?
De même pour les éventuelles autres fonctionnalités annexes.

net.yacy.cora.geo.IntegerGeoPoint

Je ne saisis pas pourquoi il y a les coordonnées géographiques de Socotra, seules, dans le main. :grin:

1 « J'aime »

Salut,

Je ne veux pas regarder le code pour le moment, sinon je vais me disperser et n’avancer ni ce que j’ai à finir, ni Yacy. Cela dit, si tu (et éventuellement d’autres) veux t’y plonger, ça fera toujours avancer un peu le schmilblic !

Aïe ! Je craignais un peu ça, et l’utilisation de solr confirme : c’est fait à la méthode moderne, qui veut à la fois tondre la pelouse et préparer le café, et ce genre de projet finit généralement par moudre le gazon et tailler l’eau chaude (quand il survit…) :frowning: Où donc est passée la philosophie des hackers (principalement d’Unix, mais pas que) « On fait une chose, et on la fait bien » ?

Bon, effectivement, ça va être un truc à regarder de plus près. Je pense qu’il doit y avoir la moitié des fonctionnalités de solr qui sont totalement inutiles… Mais trouver un équivalent, même simplifié, ça risque d’être difficile. Je dirais qu’on va probablement avoir le choix entre deux alternatives : se repalucher en C les parties utiles de Solr (mais je crains que ce soit du genre noeud de vipères : quand tu as trouvé comment attraper un bout sans te faire mordre, tu as tout qui vient et c’est indémêlable), soit il va falloir trouver ou écrire séparément les fonctions nécessaires, ce qui est effectivement beaucoup de boulot !

En tous cas, pas étonnant qu’une telle usine à gaz soit lente et très gourmande ! En revanche, si on arrive à faire quelque chose de plus simple, la différence devrait être spectaculaire !

Bon, ça, ça ne m’inquiète pas trop. Je suppose que c’est assez bien fait pour être rajouté peu à peu, langue par langue. Et donc que c’est assez indépendant du reste du code, et si c’est bien le cas on pourra laisser tomber dans un premier temps, puis éventuellement choisir une méthode bien foutue, pourquoi pas comme tu disais en utilisant le Wiktionnaire (ce qui, au passage, permettrait d’avoir facilement et rapidement toutes les langues).

Je ne vois pas bien l’utilité d’extensions pour un moteur de recherche ? On a besoin d’un certain nombre (relativement réduit) de fonctionnalités qui, à mon sens, doivent être répertoriées et implémentées dès le départ, le reste est du gadget inutile, amusement de développeurs qui feraient mieux de produire du code propre et fiable !

On voit ce que donnent les extensions dans Firefox, où elles sont pourtant beaucoup plus justifiées : finalement, on a un truc lent dont on ne peut même plus être sûr, certaines extensions étant codées avec les pieds et d’autres (ou les mêmes) comportent du code malveillant. Mozilla commence à prendre conscience du problème, et met en place un système de certifications.

Donc, pour moi, les évolutions ne devraient se faire que par pull requests, et c’est soit le chef de projet en mode dictateur bienveillant, soit l’équipe de devs de manière collégiale qui décide d’intégrer ou pas au final.

Donc, AMHA :

  • On ne gère pas en C/C++ de prise en charge d’extensions (ça n’empêche en rien une compatibilité avec le projet Java s’il survit, tout au plus des fonctionnalités différentes, et chacun choisira l’usine à gaz lente et gourmande qui tond la pelouse et fait le café ou le moteur de recherche rapide et efficace : il en faut pour tous les goûts :wink:
  • On intègre d’office les extensions nécessaires pour couvrir les fonctionnalités préalablement répertoriées comme étant nécessaires ou vraiment utiles.

Heu… Je ne suis pas sûr de bien comprendre ta question ? Il faudrait peut-être que je jette un oeil au wiki, mais bon… Normalement, sauf si Yacy Java est bourré de gadgets inutiles, on devrait avoir au final à peu près la même chose, et donc le même wiki, quitte à ajouter dans l’existant les quelques inévitables petites différences.

Maintenant, si au final on aboutit à quelque chose d’assez différent, oui, il faudra peut-être un wiki à part. Il sera temps d’y penser quand Yacy C sera opérationnel ou proche de l’être.

Par contre, si tu te mets vraiment à travailler sur le projet, il faudra peut-être qu’on mette en place un moyen pratique de communiquer, surtout si on n’est pas que deux (et je rappelle au passage qu’on aura besoin au moins de traducteurs et de graphistes) : forum, liste de diffusion… On pourrait le faire ici, mais je crains que ce soit mal adapté… et probablement peu souhaitabe autant pour l’équipe du projet que pour Framasoft… Mais bon, ce n’est pas un problème, je peux assez facilement installer et héberger un FluxBB ou autre (AMHA, PhpBB est un peu lourd pour nos besoins).

Bon, et puis s’il faut vraiment un Wiki, je peux aussi l’installer et l’héberger, mais est-ce bien raisonnable de se donner du travail supplémentaire pour le remplir ?

C’est vrai, ça. J’aurais mieux compris pour Java :stuck_out_tongue_winking_eye:

Pas de souci ! J’essaie effectivement de prendre de l’avance pendant mes nuits blanches :wink:

Pour Solr j’essaierai de regarder la documentation et le code en regardant comment c’est utilisé pour voir ce dont on a besoin et comment c’est fait.

Pour les synonymes : bonne nouvelle, il s’agit effectivement de fichiers à part.

Pour les extensions, on est du même HA et ceux qui voudront plus que ce qui sera proposé pourront toujours faire un fork.

Pour le Wiki, désolé de m’être mal exprimé, je parlais du logiciel Wiki intégré à Yacy (je crois qu’il intègre également une page d’accueil en plus de la page de recherche). Je pense que ces fonctionnalités devraient être installées séparément si l’administrateur le souhaite, que ce sont d’autres logiciels qui n’ont rien à voir (et je ne dis pas ça juste pour avoir moins de code à traduire).

Pendant qu’on en parle, une contribution au Wiki (documentation) pourra être envisagée par ailleurs.

1 « J'aime »

Salut,

Je suis cette discussion avec intérêt, j’ai testé Yacy à plusieurs reprises ces dernières années, à chaque fois sans qu’il soit vraiment utilisable, mais je trouve le projet super intéressant. Du coup je fais partie des enthousiastes et potentiels testeurs, même si je ne peux rien faire côté code !

Je me permets une petite suggestion, en espérant qu’elle ne soit pas à côté de la plaque : il faudrait prévoir un usage spécifique serveur pour yacy. Si j’ai bien compris comment fonctionne yacy, l’idée c’est que le logiciel soit à la fois client et serveur : chaque PC qui l’utilise en profite pour crawler le web en arrière plan, et aider les autres à trouver ce qu’ils cherchent.
En plus de ça, pour améliorer les résultats et le nombre de pairs connectés, il faudrait pouvoir avoir un usage uniquement “serveur”, qu’on puisse installer sur n’importe quel serveur qui tourne en permanence, crawle le web et participe à fournir des résultats. J’auto-héberge pas mal de trucs sur un serveur yunohost chez moi, et je pourrais facilement faire tourner une instance yacy dessus.
Vu qu’un des points critiques de Yacy est d’avoir suffisamment de pairs pour fonctionner, on peut imaginer une campagne de com pour qu’un maximum de gens l’installent sur leurs serveurs (via les chatons, yunohost, etc…), avec une installation la plus simple possible, pour aider à le lancer. Par contre il faut bien gérer les ressources qu’on y alloue, et les priorités d’usage de ces ressources.

2 « J'aime »

Salut,

Un fork ou un pull request : je ne suis pas systématiquement contre des extensions de fonctionnalités, mais je tiens effectivement à ce que ce soit un moteur de recherche, pas une usine à gaz. Donc disons qu’en gros tout ce qui peut améliorer les choix de filtrage de résultats ou l’indexation des sites serait à intégrer, tout ce qui tend à en faire une tondeuse à gazon ou une cafetière fera l’objet d’un fork si quelqu’un y tient.

Un logiciel wiki intégré ? :astonished:
C’est peut-être mieux que je n’aie pas pu installer Yacy (et donc tester et donc voir ça), parce que là, je serais parti en courant ! Ça me semble encore moins utile qu’y avoir intégré une machine de Goldberg !

Merci pour ton intervention et ta suggestion, @tomdereub :slight_smile: Prévoir d’intégrer Yacy à Yunohost serait effectivement une bonne idée. Je comprends un peu moins la fonction serveur seul : qui voudrait l’installer et utiliser un autre moteur pour ses recherches ? Il doit y avoir quelque chose qui m’échappe, parce que je n’en vois pas l’intérêt. Pour ce qui est des ressources, on verra à l’usage, mais j’espère bien qu’une fois ré-écrit en C et débarrassé des gadgets inutiles, Yacy retrouvera un appétit normal ne nécessitant pas ce genre de mesures : c’est ce genre de logiciel fait de plusieurs couches et bourré de choses inutiles qui donne sa raison d’être à la loi de Wirth (connue parfois sous l’appellation « loi de Gates », j’adore, surtout après la fameuse citation « 640k ought to be enough for anybody » :grinning:). Il ne faut quand même pas oublier que pour aller sur la lune, l’ordinateur de bord avait 64k de ROM contenant l’ensemble des programmes et 4k de RAM. Que fait-on aujourd’hui avec un million de fois plus de RAM ? Ah, oui, au moins on peut programmer en Java, plus en assembleur ! Quel progrès !