Si je ne devais pas faire de contorsions pour accéder à ces flèches, ce serait parfait!
Je propose que j et k servent à faire défiler simplement la page, comme les flèches directionnelles, et que n et N (ou p ou autre chose) servent à sauter au nouveau commentaire suivant ou précédent.
Je suis un peu dérouté par l'action des raccourcis clavier j et k.
Dans le logiciel de référence, et aussi dans mon navigateur internet, ils permettent de faire défiler la page ligne à ligne. Or, sur le nouveau linuxfr, ils nous projettent au nouveau contenu suivant ou précédent, faisant fi de tout ce qu'il y a avant.
Du coup, je ne peux plus faire défiler la page au clavier...
Le problème, c'est qu'elle repose sur une version antérieure du protocole randr, et j'ai peur que ça grince un peu... Je lis le man concernant l'option --q12: "Forces the usage of the RandR version 1.2 protocol, even if the display does not report it as supported or a higher version is available".
Du coup, je voulais savoir faire comment m'en sortir avec la matrice au cas où...
Je plussoie la distinction entre LaTex et Tex pour la comparaison avec Groff, et précise:
- S'il faut comparer *roff avec quelque chose, c'est avec Tex. Il n'est pas certain que *roff soit perdant dans cette comparaison - pensez à Heirloom Troff, qui intègre les fonctions de micro-typographie, supporte les polices open-type et l'utf8 nativement.
- S'il faut comparer LaTeX avec quelque chose, c'est avec l'une des macros *roff. Là, pour le coup, LaTeX sort tout de suite gagnant, car les macros *roff sont peu étendues. Mais, il n'est probablement pas impossible de créer une macro *roff à la hauteur de LaTeX ou XeTeX.
Concernant la syntaxe il me semble important de rappeller qu'elle est largement définie par la macro utilisée (hormis pour le retour à la ligne imposé). La macro mom utilise par exemple des mots entiers (AUTHOR, DOCTYPE, FROM, GREETING, etc.).
D'autre part, il est possible de modifier l'opérateur signalant une macro ('.' par défaut). Dès lors, on pourrait préférer l'opérateur < et créer les macros p>, h1>, ul>, etc., pour ouvrir une séquence, et les macros /p>, /h1>, /ul>, etc., pour la fermer. Et pour le coup, une simple ligne sed permet d'introduire les retours à la ligne là où il faut.
En fait, moi aussi je préfère utiliser \fB...\fP. Le problème survient lorsque plusieurs commandent commençant par \ s'enchaînent, comme c'est le cas dans la macro CROIX qui sert d'exemple ci-dessus: c'est illisible.
Quant à la macro ms, je l'ai d'abord choisie ici parce qu'est c'est celle que j'utilise. Et je l'utilise parce que lorsque j'ai commencé à étudier groff, il m'a semblé que c'était la macro la plus simple pour commencer - et finalement, je n'en ai pas essayé d'autres.
Il y a une raison plus générale qui motive le choix de la macro ms: cette macro est réputée être celle qui est le plus facilement modifiable. J'ai vu cela écrit quelques fois dans la liste de diffusion de groff, je sais que Peter Schaffter, le créateur de la macro mom s'est inspiré de cette macro, et c'est aussi l'exemple qu'utilisent Dale Rougherty et Tim O'Reilly dans Unix Text Processing.
Comme, à mon avis, la puissance de *roff se dévoile lorsque l'on est en mesure d'écrire ses propres macros, chose qui ne devrait pas être insurmontable pour le public de dlfp, le choix de ms s'imposait d'une certaine façon.
Pour un public moins averti, j'aurais probablement choisi mom comme exemple. Ce sera peut-être pour une prochaine fois...
Je me suis fait la même réflexion la première fois que j'ai vu un document *roff, mais à l'usage, je finis par l'apprécier cette syntaxe - sans vraiment savoir pourquoi.
C'est un peu comme python: elle force l'aspect visuel du fichier source, et avec un peu d'habitude, on finit par s'y retrouver très vite. Les lignes des fichiers *roff sont généralement courtes, ce qui rend le code des macros, AMHA, agréable à lire.
Pour respecter cet esprit, quand je tape un texte pour *roff, vim force le retour de ligne à 60 caractères, et j'ai pris l'habitude de travailler avec deux colonnes.
Par contre, c'est vrai que toutes les commandes inline, celles qui utilisent le \ sont illisibles.
Il y a quelques fautes, dont deux qui affectent le code des exemples:
collègue Josef Osanna -> collègue Brian Kernighan
txt2tags -> txt2tags,
. groff -> . Groff
par Groff -> par groff
Dieu sans l'être -> Dieu sans l'\[e ^]tre
# suite -> .\" suite
Merci à l'équipe pour l'introduction des balises de titre et les autres corrections!
Normalement, la commande 'database' indique à refer où chercher la liste des références, et la macro ms utilisée ici affiche alors celles-ci en note de bas de page.
À la lecture de la commande 'bibliography' refer liste toutes les références, ce qui est utile en fin de document.
Chez moi ça marche! (hormis quelques typos corrigées plus bas)
Merci pour ces remarques. J'aurais besoin de quelques précisions:
Le manque de cadre se fait-il sentir dans la liste des dépêches ou dans l'affichage d'une dépêche en particulier?
Dans les deux cas, n'est-ce pas plutôt le haut de la page qui est trop surchargé, ce qui empêche l'œil de se fixer sur le point essentiel?
Par exemple, est-ce que lorsque vous avancez dans la liste des dépêches, ou lorsque vous avancez dans la lecture de la dépêche de Patrick_g sur le noyau, l'absence de cadre vous semble dommageable (disons, par exemple, ici: [https://alpha.linuxfr.org/news/le-noyau-linux-2636-est-dispo(...)]). Ici, j'ai l'impression que le manque de cadre n'est pas très gênant, par contre, il me semble que l'œil peine à repérer les début des paragraphes, ce qui peut-être résolu par l'ajout d'indentation.
Concernant la liste des dépêches, plus que l'absence de cadre, n'est-ce pas la difficulté à distinguer les dépêches les unes des autres qui est gênante?
À vrai dire, 36em c'est encore trop. Les lignes idéales devraient contenir environ de 70 caractères. Cela est flagrant concernant les commentaires, qui ont des lignes beaucoup plus longues: l'œil peine à la parcourir en entier, et préfère la survoler.
De mon point de vue, ce n'est donc pas la largeur de l'écran qui doit être déterminante ici, mais la taille de la police: La taille du bloc doit suivre celle de la police pour finalement couper les lignes à environ 70 caractères.
Néanmoins, mon argument tombe un peu à l'eau, car la lisibilité que je défends ici n'est de toute évidence pas au rendez-vous concernant les contrastes et les repères.
Les couleurs - qui ne sont que provisoires - y sont pour beaucoup, mais c'est vrai, l'absence de bordures aussi. Mais j'ai aussi remarqué qu'il y a un petit temps d'adaptation nécessaire pour trouver de nouveaux repères dans l'architecture des pages.
Quoi qu'il en soit, il est certain que je n'ai pas encore trouvé le moyen de créer les contrastes suffisant tout en conservant le style épuré.
Pour un usage local, il est simple et efficace, et, à ma connaissance, irremplaçable.
Il n'y a pas que les projets logiciels qui ont besoin de conserver un historique des évolutions, il y a aussi:
- Les écrits au long cours (cours, mémoires, thèses).
- Les petits scripts qui évoluent tout le temps.
- Certains fichiers de configuration.
- Son carnet d'adresse
- ...
Pour ma part, RCS me sert surtout dans le premier cas. Il est un compagnon essentiel des processeurs de textes tels Tex et Roff.
Je suis heureux, outre l'avancée de Bredele, d'apprendre l'existence de Biblatex.
Il y a quelques années, j'avais dû modifier un fichier de sytle bibtex pour parvenir à afficher à peu près correctement les références bibliographiques. Résultat, sitôt mon mémoire terminé, j'ai décidé d'abandonner Latex...
Dans mon souvenir, Bredele non plus ne répondait pas à mes attentes à l'époque. J'ai l'impression que l'arrivée de Biblatex a permis une avancée importante de Bredele concernant l'affichage des références bibliographiques. Est-ce bien le cas?
Wikipedia indique que gajim et pidgin sont installables sur windows:
– « Depuis la version 2.6 pidgin supporte la vidéo et la VoIP pour le protocole XMPP » (vraissemblablement via le protocole jingle).
– Gajim supportera le protocole jingle dans sa prochaine version, qui devrait être pour bientôt: [http://trac.gajim.org/roadmap].
Ce protocole jingle est probablement celui qu'utilise google pour le chat vidéo.
C'est aussi ce protocole qu'utilise IChat sur mac, Psi avec le toolkit KDE (« Voix par Jingle en version alpha (expérimentale), non-compilée, et seulement pour Linux et Mac OS X »), et jabbin (uniquement la voix, et seulement sous linux).
Donc, a priori, depuis la version 2.6 de pidgin, il est possible de faire du chat vidéo entre linux et windows; et dorénavant, on peut choisir son logiciel client.
Je connais tous ces liens. Je n'ai fait que survoler le dernier pdf, trop technique pour moi.
En fait j'ai l'impression que mes questions ne peuvent trouver de réponse actuellement, puisque je voudrais connaître l'implémentation des techniques et des objectifs décrites sur le site.
Tant que cette implémentation n'est pas faite, il est normal qu'on ne puisse pas la décrire.
J'attendrai donc patiemment que la prochaine version sorte pour l'essayer, et pour me faire une idée par moi-même.
Le lien répond en partie à ma question. Je l'avais déjà lu, il est plus précis que je ne m'en souvenais, mais reste un peu flou pour moi.
Concernant « Hippy », dont la livraison est prévue en automne (n'est-ce pas?), en fonction de quoi les résultats de recherche seront-ils réorganisés? Est-ce en fonction des statistiques de liens cliqués par les utilisateurs? Y aura-t-il un système de vote des bons liens? Est-ce par discussion collaborative?
Peut-être que tout cela est justement en discussion chez les développeurs de Seeks, mais comme l'automne arrive bientôt, je me dis qu'il doit y avoir plusieurs choses d'ores et déjà décidées.
Justement, il a pour objectif de ne pas rester un méta-moteur. Mieux, il a pour projet de substituer un mode de recherche décentralisé au mode actuel qui est centralisé.
À mon avis (avis qui ne repose sur rien de rationnel), si le protocole de pair à pair est bien pensé, cela est promis à un bel avenir. Je ne suis même pas certain que la masse critique pour que ça fonctionne soit réellement importante: une petite communauté d'utilisateurs aux goûts divers doit rapidement débroussailler un champ du web susceptible de répondre aux requêtes les plus fréquentes.
Quant à la possibilité que les moteurs de recherchent bloquent les méta-moteur, cela n'affecte pas Seek, puisque, justement, il est décentralisé: comment le méta-moteur peut-il savoir que la requête vient de seek et pas de firefox?
Après, il est certain que si personne ne l'utilise, il ne fonctionnera jamais...
[^] # Re: Des raccourcis clavier
Posté par Sygne (site web personnel) . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 1.
Bof.
Ce n'est qu'un avis. Si je suis le seul à penser cela, ça n'a rien à faire dans le suivi.
[^] # Re: Des raccourcis clavier
Posté par Sygne (site web personnel) . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 3.
Ah oui, ça marche!
Si je ne devais pas faire de contorsions pour accéder à ces flèches, ce serait parfait!
Je propose que j et k servent à faire défiler simplement la page, comme les flèches directionnelles, et que n et N (ou p ou autre chose) servent à sauter au nouveau commentaire suivant ou précédent.
# Des raccourcis clavier
Posté par Sygne (site web personnel) . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 1.
Je suis un peu dérouté par l'action des raccourcis clavier j et k.
Dans le logiciel de référence, et aussi dans mon navigateur internet, ils permettent de faire défiler la page ligne à ligne. Or, sur le nouveau linuxfr, ils nous projettent au nouveau contenu suivant ou précédent, faisant fi de tout ce qu'il y a avant.
Du coup, je ne peux plus faire défiler la page au clavier...
Ça ne déroute que moi?
[^] # Re: Raccourcis vim
Posté par Sygne (site web personnel) . En réponse à la dépêche Les résultats du concours LinuxFr.org. Évalué à 1.
Par contre, j ne fonctionne pas de la même façon: il passe au nœud suivant, au lieu de simplement faire défiler la page...
J'eusse préféré que j fasse défiler la page, et que n passe au nœud suivant.
# Merci à tous!
Posté par Sygne (site web personnel) . En réponse au message Réflextion avec Xrandr. Évalué à 2.
[^] # Re: VLC
Posté par Sygne (site web personnel) . En réponse au message Réflextion avec Xrandr. Évalué à 2.
Il y a d'ailleurs une option du même goût dans mplayer:
geq=equation. Par ex. 'p(W-X\,Y)' pour retourner l'image horizontalement.
[^] # Re: --reflect
Posté par Sygne (site web personnel) . En réponse au message Réflextion avec Xrandr. Évalué à 1.
Le problème, c'est qu'elle repose sur une version antérieure du protocole randr, et j'ai peur que ça grince un peu... Je lis le man concernant l'option --q12: "Forces the usage of the RandR version 1.2 protocol, even if the display does not report it as supported or a higher version is available".
Du coup, je voulais savoir faire comment m'en sortir avec la matrice au cas où...
(On n'est jamais trop prévoyant)
[^] # Re: Selon moi...
Posté par Sygne (site web personnel) . En réponse au message Réflextion avec Xrandr. Évalué à 1.
Sauf que, c'est l'axe horizontal qu'il faut symétriser. Ce serait donc:
-1 0 0
0 1 tx
0 0 1
Non?
[^] # Re: a defaut du videoprojecteur
Posté par Sygne (site web personnel) . En réponse au message Réflextion avec Xrandr. Évalué à 1.
Je suis quand même heureux de constater que je ne suis pas le seul à ne rien y entendre en calcul matriciel!
[^] # Re: Syntaxe
Posté par Sygne (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 2.
- S'il faut comparer *roff avec quelque chose, c'est avec Tex. Il n'est pas certain que *roff soit perdant dans cette comparaison - pensez à Heirloom Troff, qui intègre les fonctions de micro-typographie, supporte les polices open-type et l'utf8 nativement.
- S'il faut comparer LaTeX avec quelque chose, c'est avec l'une des macros *roff. Là, pour le coup, LaTeX sort tout de suite gagnant, car les macros *roff sont peu étendues. Mais, il n'est probablement pas impossible de créer une macro *roff à la hauteur de LaTeX ou XeTeX.
Concernant la syntaxe il me semble important de rappeller qu'elle est largement définie par la macro utilisée (hormis pour le retour à la ligne imposé). La macro mom utilise par exemple des mots entiers (AUTHOR, DOCTYPE, FROM, GREETING, etc.).
D'autre part, il est possible de modifier l'opérateur signalant une macro ('.' par défaut). Dès lors, on pourrait préférer l'opérateur < et créer les macros p>, h1>, ul>, etc., pour ouvrir une séquence, et les macros /p>, /h1>, /ul>, etc., pour la fermer. Et pour le coup, une simple ligne sed permet d'introduire les retours à la ligne là où il faut.
[^] # Re: Syntaxe
Posté par Sygne (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 2.
Quant à la macro ms, je l'ai d'abord choisie ici parce qu'est c'est celle que j'utilise. Et je l'utilise parce que lorsque j'ai commencé à étudier groff, il m'a semblé que c'était la macro la plus simple pour commencer - et finalement, je n'en ai pas essayé d'autres.
Il y a une raison plus générale qui motive le choix de la macro ms: cette macro est réputée être celle qui est le plus facilement modifiable. J'ai vu cela écrit quelques fois dans la liste de diffusion de groff, je sais que Peter Schaffter, le créateur de la macro mom s'est inspiré de cette macro, et c'est aussi l'exemple qu'utilisent Dale Rougherty et Tim O'Reilly dans Unix Text Processing.
Comme, à mon avis, la puissance de *roff se dévoile lorsque l'on est en mesure d'écrire ses propres macros, chose qui ne devrait pas être insurmontable pour le public de dlfp, le choix de ms s'imposait d'une certaine façon.
Pour un public moins averti, j'aurais probablement choisi mom comme exemple. Ce sera peut-être pour une prochaine fois...
[^] # Re: Syntaxe
Posté par Sygne (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 2.
C'est un peu comme python: elle force l'aspect visuel du fichier source, et avec un peu d'habitude, on finit par s'y retrouver très vite. Les lignes des fichiers *roff sont généralement courtes, ce qui rend le code des macros, AMHA, agréable à lire.
Pour respecter cet esprit, quand je tape un texte pour *roff, vim force le retour de ligne à 60 caractères, et j'ai pris l'habitude de travailler avec deux colonnes.
Par contre, c'est vrai que toutes les commandes inline, celles qui utilisent le \ sont illisibles.
# Typos
Posté par Sygne (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 3.
collègue Josef Osanna -> collègue Brian Kernighan
txt2tags -> txt2tags,
. groff -> . Groff
par Groff -> par groff
Dieu sans l'être -> Dieu sans l'\[e ^]tre
# suite -> .\" suite
Merci à l'équipe pour l'introduction des balises de titre et les autres corrections!
[^] # Re: Intéressant...
Posté par Sygne (site web personnel) . En réponse à la dépêche Groff sort en version 1.21. Évalué à 3.
Normalement, la commande 'database' indique à refer où chercher la liste des références, et la macro ms utilisée ici affiche alors celles-ci en note de bas de page.
À la lecture de la commande 'bibliography' refer liste toutes les références, ce qui est utile en fin de document.
Chez moi ça marche! (hormis quelques typos corrigées plus bas)
[^] # Re: Commentaires à un mot par ligne
Posté par Sygne (site web personnel) . En réponse au journal css pour alpha.linuxfr. Évalué à 2.
Bon, au boulot alors...
Merci!
[^] # Re: Cadre
Posté par Sygne (site web personnel) . En réponse au journal css pour alpha.linuxfr. Évalué à 1.
Le manque de cadre se fait-il sentir dans la liste des dépêches ou dans l'affichage d'une dépêche en particulier?
Dans les deux cas, n'est-ce pas plutôt le haut de la page qui est trop surchargé, ce qui empêche l'œil de se fixer sur le point essentiel?
Par exemple, est-ce que lorsque vous avancez dans la liste des dépêches, ou lorsque vous avancez dans la lecture de la dépêche de Patrick_g sur le noyau, l'absence de cadre vous semble dommageable (disons, par exemple, ici: [https://alpha.linuxfr.org/news/le-noyau-linux-2636-est-dispo(...)]). Ici, j'ai l'impression que le manque de cadre n'est pas très gênant, par contre, il me semble que l'œil peine à repérer les début des paragraphes, ce qui peut-être résolu par l'ajout d'indentation.
Concernant la liste des dépêches, plus que l'absence de cadre, n'est-ce pas la difficulté à distinguer les dépêches les unes des autres qui est gênante?
[^] # Re: chouette
Posté par Sygne (site web personnel) . En réponse au journal css pour alpha.linuxfr. Évalué à 1.
De mon point de vue, ce n'est donc pas la largeur de l'écran qui doit être déterminante ici, mais la taille de la police: La taille du bloc doit suivre celle de la police pour finalement couper les lignes à environ 70 caractères.
Néanmoins, mon argument tombe un peu à l'eau, car la lisibilité que je défends ici n'est de toute évidence pas au rendez-vous concernant les contrastes et les repères.
[^] # Re: Pas mal… mais pas si lisible !
Posté par Sygne (site web personnel) . En réponse au journal css pour alpha.linuxfr. Évalué à 1.
Les couleurs - qui ne sont que provisoires - y sont pour beaucoup, mais c'est vrai, l'absence de bordures aussi. Mais j'ai aussi remarqué qu'il y a un petit temps d'adaptation nécessaire pour trouver de nouveaux repères dans l'architecture des pages.
Quoi qu'il en soit, il est certain que je n'ai pas encore trouvé le moyen de créer les contrastes suffisant tout en conservant le style épuré.
# [x] RCS
Posté par Sygne (site web personnel) . En réponse au sondage Mon logiciel de Logiciel de gestion de versions favori est :. Évalué à 2.
Il n'y a pas que les projets logiciels qui ont besoin de conserver un historique des évolutions, il y a aussi:
- Les écrits au long cours (cours, mémoires, thèses).
- Les petits scripts qui évoluent tout le temps.
- Certains fichiers de configuration.
- Son carnet d'adresse
- ...
Pour ma part, RCS me sert surtout dans le premier cas. Il est un compagnon essentiel des processeurs de textes tels Tex et Roff.
# Biblatex
Posté par Sygne (site web personnel) . En réponse au journal Sortie de Bredele 2.0. Évalué à 2.
Il y a quelques années, j'avais dû modifier un fichier de sytle bibtex pour parvenir à afficher à peu près correctement les références bibliographiques. Résultat, sitôt mon mémoire terminé, j'ai décidé d'abandonner Latex...
Pour rappel, l'affichage des références bibliographiques est soumis, à la norme iso-690-2:
http://www.revue-texto.net/Reperes/Themes/Kyheng_References.(...)
Dans mon souvenir, Bredele non plus ne répondait pas à mes attentes à l'époque. J'ai l'impression que l'arrivée de Biblatex a permis une avancée importante de Bredele concernant l'affichage des références bibliographiques. Est-ce bien le cas?
[^] # Re: pour faire different
Posté par Sygne (site web personnel) . En réponse au journal Softs qui déchiraizent \o/. Évalué à 1.
- Vim
- Groff
- heirloom mailx (pas tout à fait édition, mais, amha, incontournable).
Ça couvre 80% de mes besoins. Le reste, c'est surtout le navigateur internet, mais je n'ai pas encore trouvé la perle qui me convient...
[^] # Re: Empathy, Gajim, Pidgin
Posté par Sygne (site web personnel) . En réponse au journal google chat: enfin une solution vidéo aboutie pour les distributions les plus répandues (debian et ubuntu). Évalué à 1.
– « Depuis la version 2.6 pidgin supporte la vidéo et la VoIP pour le protocole XMPP » (vraissemblablement via le protocole jingle).
– Gajim supportera le protocole jingle dans sa prochaine version, qui devrait être pour bientôt: [http://trac.gajim.org/roadmap].
Ce protocole jingle est probablement celui qu'utilise google pour le chat vidéo.
C'est aussi ce protocole qu'utilise IChat sur mac, Psi avec le toolkit KDE (« Voix par Jingle en version alpha (expérimentale), non-compilée, et seulement pour Linux et Mac OS X »), et jabbin (uniquement la voix, et seulement sous linux).
Donc, a priori, depuis la version 2.6 de pidgin, il est possible de faire du chat vidéo entre linux et windows; et dorénavant, on peut choisir son logiciel client.
[^] # Re: Question
Posté par Sygne (site web personnel) . En réponse à la dépêche Sortie de Seeks en version stable 0.2.4. Évalué à 1.
En fait j'ai l'impression que mes questions ne peuvent trouver de réponse actuellement, puisque je voudrais connaître l'implémentation des techniques et des objectifs décrites sur le site.
Tant que cette implémentation n'est pas faite, il est normal qu'on ne puisse pas la décrire.
J'attendrai donc patiemment que la prochaine version sorte pour l'essayer, et pour me faire une idée par moi-même.
Merci pour tout!
[^] # Re: Question
Posté par Sygne (site web personnel) . En réponse à la dépêche Sortie de Seeks en version stable 0.2.4. Évalué à 2.
Concernant « Hippy », dont la livraison est prévue en automne (n'est-ce pas?), en fonction de quoi les résultats de recherche seront-ils réorganisés? Est-ce en fonction des statistiques de liens cliqués par les utilisateurs? Y aura-t-il un système de vote des bons liens? Est-ce par discussion collaborative?
Peut-être que tout cela est justement en discussion chez les développeurs de Seeks, mais comme l'automne arrive bientôt, je me dis qu'il doit y avoir plusieurs choses d'ores et déjà décidées.
[^] # Re: Beau projet mais dommage...
Posté par Sygne (site web personnel) . En réponse à la dépêche Sortie de Seeks en version stable 0.2.4. Évalué à 4.
À mon avis (avis qui ne repose sur rien de rationnel), si le protocole de pair à pair est bien pensé, cela est promis à un bel avenir. Je ne suis même pas certain que la masse critique pour que ça fonctionne soit réellement importante: une petite communauté d'utilisateurs aux goûts divers doit rapidement débroussailler un champ du web susceptible de répondre aux requêtes les plus fréquentes.
Quant à la possibilité que les moteurs de recherchent bloquent les méta-moteur, cela n'affecte pas Seek, puisque, justement, il est décentralisé: comment le méta-moteur peut-il savoir que la requête vient de seek et pas de firefox?
Après, il est certain que si personne ne l'utilise, il ne fonctionnera jamais...