Miniflux, un lecteur de flux RSS minimaliste

Posté par (page perso) . Édité par baud123 et Lucas Bonnet. Modéré par patrick_g. Licence CC by-sa
Tags :
48
19
mar.
2013
Internet

Miniflux est un lecteur de flux RSS minimaliste. C'est une application web simple et facile à utiliser. L'affichage des articles est optimisé pour la lecture sur écran.

De plus son installation se résume à un simple copier/coller du code source. Il n'y a aucune configuration nécessaire. Toutes les données sont stockées dans une base de données Sqlite.

J'ai développé Miniflux pour mon propre usage et j'ai décidé de le distribuer le code sous licence libre (AGPL).

Vue générale

Fonctionnalités

Optimisé pour la lecture

La mise en page, les polices d'écritures et les couleurs ont été choisies pour faciliter la lecture sur écran. En effet, la chose la plus importante est le contenu.

Très simple à utiliser

Je suppose que vous n'aimez pas les logiciels de type usine à gaz ? L'interface utilisateur a été pensée pour être la plus simple possible.

Design minimaliste

Il n'y a aucune fonctionnalités fantaisistes. Donc pas de trucs kikoo lol 2.0. Rappelez-vous : Less is more :)

Pas de tags, pas de catégories, pas de stats, pas d'api

Je veux simplement lire mes abonnements. Pas besoin de tout cela… Vous connaissez la citation d'Antoine de Saint-Exupéry ?

La perfection est enfin atteinte non pas lorsqu'il n'y a plus rien à ajouter mais lorsqu'il n'y a plus rien à enlever.

Plusieurs méthodes de mise à jour

Vous pouvez mettre à jour vos abonnements depuis une tâche planifiée (cronjob) ou depuis l'interface web (Ajax). Dans le second cas, il y a par défaut au maximum 5 requêtes Ajax qui sont exécutées en parallèle.

Aucune intégration avec les réseaux sociaux

Je n'aime pas les réseaux sociaux à la Facebook ou Google+. Il n'y a donc aucune forme de partage, d'envoi par email ou encore de système de favoris.

Suppression des publicités et du tracking utilisateur

Personne n'aime les publicités dans les flux RSS. Les publicités de Feedburner sont supprimées ainsi que tous les "pixel trackers" (images de 1px sur 1px utilisés par les outils de stats).

Vie privée

Personne n'a besoin de savoir d'où vous venez. Tous les liens s'ouvrent dans un nouvel onglet avec l'attribut rel="noreferrer", pris en charge uniquement par Webkit malheureusement.

Aucun emprisonnement de vos données

Vous pouvez importer ou exporter vos abonnements au format OPML. Cette application web est prévue pour être auto-hébergée, soit sur votre propre serveur, soit sur un hébergement mutualisé. Miniflux est développé en PHP (5.3 minimum) et nécessite les extensions XML et Sqlite.

Mobile

Vous pouvez utiliser Miniflux depuis votre smartphone, tablette tactile ou votre ordinateur de bureau. L'application a été testée uniquement sur les navigateurs modernes, comme Firefox et ceux basés sur Webkit.

Cependant, il n'y a pas de mode hors-ligne pour le moment. Mais, si vous le souhaitez vraiment, vous pouvez installer l'application en local.

Sécurité

Le Javascript contenu dans les articles est supprimé automatiquement. De plus, les entêtes HTTP qui permettent de renforcer la sécurité de l'application sont utilisés (Content Security Policies). Par défaut, seulement les images externes sont autorisées.

Installation super simple

La seule chose à faire se résume à un copier/coller des fichiers sur votre serveur web. Il n'y a pas de fichier de configuration, pas de base de données Mysql. Tout est stocké dans un fichier Sqlite.

Contributions, idées et commentaires constructifs sont acceptés

Miniflux est diffusé sous licence AGPL. Le code est sur Github.

  • # Service en ligne

    Posté par (page perso) . Évalué à  10 . Dernière modification : le 19/03/13 à 11:02

    Bravo pour ton

    Would you like a hosted version of this software by paying a small fee like $1/month?

    Parce qu'il est temps que l'on propose des services en ligne et pas que du logiciel à s'installer, configurer et s'héberger soit même. Et qu'il n'y a pas de raison que ce service en ligne soit forcément gratuit. Le paiement en bitcoin serait top :)

    Sinon que pense tu de l'idée de supporter remotestorage ?

    • [^] # Re: Service en ligne

      Posté par (page perso) . Évalué à  3 .

      Avant de le proposer sous forme de service en ligne, je vais attendre que le projet soit un peu plus mature car jusqu'a présent j'étais le seul utilisateur. C'est à dire qu'au minimum, je souhaite corriger tous les bugs que l'on me rapporte.

      Moi aussi j'avais pensé à Bitcoin, il me faut juste un peu de temps pour voir comment ca fonctionne et voir comment je pourrais intégrer cela.

      Je ne connais pas remotestorage, et je n'ai aucune idée si c'est trivial à mettre en place et si c'est stable.

    • [^] # Re: Service en ligne

      Posté par (page perso) . Évalué à  10 .

      Le paiement en bitcoin serait top :)

      Sérieux ? Il y a des gens qui l'utilisent ?

  • # décidément on commence à avoir du choix

    Posté par (page perso) . Évalué à  10 .

    • Leed
    • KrISS Feed
    • FreshRSS
    • Aeres
    • selfoss
    • RSS Lounge
    • cartulary
    • RSSMiner
    • Gregarius
    • NewsBlur
    • FeedHQ
    • Tiny Tiny RSS
    • et maintenant : Miniflux !!

    j'en oublie surement, vive le libre :)

    • [^] # Re: décidément on commence à avoir du choix

      Posté par (page perso) . Évalué à  9 .

      Et quand on n'aime pas les serveurs de bases de données :

      • kriss feed
      • Aeres
      • selfoss
      • RSSMiner
      • Gregarius
      • Miniflux
      • [^] # Re: décidément on commence à avoir du choix

        Posté par (page perso) . Évalué à  3 .

        RSSMiner utilise MySQL comme datastore.

      • [^] # Re: décidément on commence à avoir du choix

        Posté par (page perso) . Évalué à  5 .

        Tu as quoi contre les serveurs de bases de données?

        • [^] # Re: décidément on commence à avoir du choix

          Posté par (page perso) . Évalué à  5 . Dernière modification : le 19/03/13 à 12:23

          Dans ce cas précis, le fait que ce moyen de stockage soit inutile et inapproprié (il s'agit de stocker grosso modo une liste de flux, pour chaque flux une liste d'articles lus, et un cache des articles en question), et que ça complique l'installation. Pas de serveur de base de donnée sur mon serveur.

          L'utilisation de bases de données provient surtout d'une maladie qui touche les développeurs PHP, qui les pousse à utiliser une base de données, de préférence MySQL, dès qu'il s'agit de stocker quelque chose.

          • [^] # Re: décidément on commence à avoir du choix

            Posté par . Évalué à  6 .

            il s'agit de stocker grosso modo une liste de flux, pour chaque flux une liste d'articles lus, et un cache des articles en question

            Personnellement j'attends un peu plus :

            • le classement des flux par tag et/ou catégorie
            • garder un historique complet des flux

            L'utilisation de bases de données provient surtout d'une maladie qui touche les développeurs PHP, qui les pousse à utiliser une base de données, de préférence MySQL, dès qu'il s'agit de stocker quelque chose.

            Je pense que les hébergeurs ne sont pas non plus totalement innocents à cette habitude.
            Par contre je pense que tu peut avoir de meilleures performances avec un moteur de base de données. Notamment grâce des index plus faciles à construire et à garder cohérent.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: décidément on commence à avoir du choix

              Posté par (page perso) . Évalué à  2 .

              • le classement des flux par tag et/ou catégorie
              • garder un historique complet des flux

              C'était le sens de mon « grosso modo ». Des trucs qui se stockent très bien dans un système de fichiers, avec des répertoires et des liens symboliques par exemple, ou de simples fichiers de configuration.

              Par contre je pense que tu peut avoir de meilleures performances avec un moteur de base de données. Notamment grâce des index plus faciles à construire et à garder cohérent.

              S'il s'agit d'utiliser un modèle relationnel, oui, mais je doute que ce soit le cas ici. Un système de fichiers, c'est indexé normalement, donc en l'utilisant intelligemment, tout va bien.

              • [^] # Re: décidément on commence à avoir du choix

                Posté par . Évalué à  1 .

                Des trucs qui se stockent très bien dans un système de fichiers, avec des répertoires et des liens symboliques par exemple, ou de simples fichiers de configuration.

                Wikipédia dit :

                Une base de données est un conteneur informatique permettant de stocker dans un même endroit l'intégralité des informations en rapport avec une activité. Une base de données permet de stocker un ensemble d'informations de plusieurs natures ainsi que les liens qu'il existe entre les différentes natures

                D'après cette définition, un filesystem est une base de donnée. Bon, il n'y a pas de «serveur», mais ton reproche

                L'utilisation de bases de données provient surtout d'une maladie qui touche les développeurs PHP, qui les pousse à utiliser une base de données, de préférence MySQL, dès qu'il s'agit de stocker quelque chose.

                est applicable à ceux qui utilisent un système de fichier comme base de donnée (Sauf pour la préférence.)

                Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: décidément on commence à avoir du choix

                Posté par . Évalué à  4 .

                Je ne suis probablement pas un spécialiste mais je pense que tu va devoir créer des fichiers d'index pour rivaliser avec une base de données quand il s'agit de montrer la liste des entrées d'un flux tout en montrer l'état lu/non lu, la date de publication et éventuellement un bout de son contenu. Tu as un grand nombre de lecture de fichiers uniques dans les quels tu doit aller chercher quelques informations.

                C'est grosso modo les même contraintes que Maildir en fait.
                D'ailleurs dans ta liste tu as oublié feed2imap.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                • [^] # Re: décidément on commence à avoir du choix

                  Posté par (page perso) . Évalué à  1 .

                  Boaf, non, un fichier par article, contenant : un en-tête avec des indicateurs lu/non lu, date, titre, et un corps avec le contenu de l'article.

                • [^] # Re: décidément on commence à avoir du choix

                  Posté par (page perso) . Évalué à  1 .

                  Il y a une question d'échelle , c'est sûr !
                  A petite échelle (auto-hébergement par exemple), les *dbm du monde Unix sont très performantes et beaucoup plus simple à mettre œuvre qu'une base MySQL. Par contre, si on envisage un passage à l'échelle d'une application Web, c'est sûr que des bases plus costaudes et prévues à cet effet ne sont pas une mauvaise option.

                  Mais il n'y a pas que le relationnel, il y a le NoSQL qui est très bien aussi, et qui défonce du mamout en barre, en terme de performances et de passage à l'échelle. Là pour le coup on revient sur une API pas très lointaine des dbm, et avec une architecture un peu maline on doit pouvoir envisager plusieurs modes de déploiement : un en auto-hébergement (dbm) et un en serveur de production (Cassandra ou autre DB NoSQL le plus libre possible).

                • [^] # Re: décidément on commence à avoir du choix

                  Posté par (page perso) . Évalué à  6 .

                  Je ne suis probablement pas un spécialiste mais je pense que tu va devoir créer des fichiers d'index pour rivaliser avec une base de données quand il s'agit de montrer la liste des entrées d'un flux tout en montrer l'état lu/non lu, la date de publication et éventuellement un bout de son contenu.

                  on peut très bien avoir un index performant sans passer par une installation de mysql. Des wiki type dokuwiki ou pmwiki n'utilisent pas de base de données relationnelles mais des fichiers plain texte, et ça ne pose pas de problèmes de performances, certains sites fortement visités les utilisent sans soucis (par exemple le wiki de Debian, d'Apache, c'est MoinMoin, pour ubuntu-fr c'est dokuwiki…), donc c'est pas sur un malheureux lecteur de flux utilisé par une seule personne qui va perdre en performance parce que ça n'utilise pas le sacro-saint mysql.

                  On en arrive au point que même un bête compteur de visite c'est fait en mysql.

                  De plus, quand on peut avoir du sqlite à la place de mysql, c'est quand même plus pratique pour migrer un site, ou tester en local et déplacer simplement ensuite le fichier sqlite sur le serveur de production.

                  En général, j'essaye d'éviter le sql dans les outils que j'utilise au quotidien, sauf s'il n'y a vraiment pas le choix.

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                  • [^] # Re: décidément on commence à avoir du choix

                    Posté par . Évalué à  4 .

                    on peut très bien avoir un index performant sans passer par une installation de mysql. Des wiki type dokuwiki ou pmwiki n'utilisent pas de base de données relationnelles mais des fichiers plain texte, et ça ne pose pas de problèmes de performances, certains sites fortement visités les utilisent sans soucis (par exemple le wiki de Debian, d'Apache, c'est MoinMoin, pour ubuntu-fr c'est dokuwiki…), donc c'est pas sur un malheureux lecteur de flux utilisé par une seule personne qui va perdre en performance parce que ça n'utilise pas le sacro-saint mysql.

                    Oula du calme, je me posais simplement la question et j'avoue que j'aimerais bien savoir comment ils font. Je n'ai jamais pensais que c'était impossible, juste que ça peut devenir assez compliqué d'avoir des index efficaces.

                    On en arrive au point que même un bête compteur de visite c'est fait en mysql.

                    Là dessus un SGBDR t'apporte la cohérence (lors des accès concurrents) que tu n'a pas facilement avec d'autres moyen de persistance.

                    En général, j'essaye d'éviter le sql dans les outils que j'utilise au quotidien, sauf s'il n'y a vraiment pas le choix.

                    Moi aussi et j'ai bien du mal à me sentir à l'aise avec l'administration de SGBD sur mon serveur mais c'est pas pour ça que je ne reconnais pas leur utilité.

                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

          • [^] # Re: décidément on commence à avoir du choix

            Posté par (page perso) . Évalué à  2 .

            C'est une méthode de stockage d'information comme une autre. En l'occurrence, au niveau des performances c'est bien mieux approprié que le système de fichiers pour stocker ce genre de choses, il me semble.

            Après, j'imagine que ta préférence va au système de fichiers parce que c'est ce que tu connais le mieux. Mais n'oublie pas que c'est une abstraction comme une autre, et que ce n'est en rien "plus simple" qu'une bases de données. C'est différent, c'est tout.

            • [^] # Re: décidément on commence à avoir du choix

              Posté par . Évalué à  2 .

              […] ce n'est en rien "plus simple" […]

              Le SGBD apporte sa part de complexité. C'est un deamon qui est accessible par réseau et qui possède en interne sa propre gestion des droits qui viens se caller en plus des droits unix.

              Même si je comprends tout à fait l'intérêt des SGBD et autre nosql on peut difficilement dire que le fs est plus compliqué. Après quand tu as des données très structurées un accès à des simples fichiers n'est pas simple (il faut faire de la (dé)sérialisation).

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re:décidément on commence àavoir du choix

                Posté par (page perso) . Évalué à  2 .

                C'est un deamon qui est accessible par réseau

                Pas forcement.

                • [^] # Re:décidément on commence àavoir du choix

                  Posté par . Évalué à  2 .

                  Soit tu parle du fait que les SGBD puissent être appelés via le loopback ou une socket unix et ça, il faut que tu te le configure. Soit tu parle de sqlite et deby utilisés comme bibliothèque et oui mais tu parle de cas particulier qui sont très peut utilisé et qui donnent un certains nombre de limitations (ou alors il faut bien les configurer pour gérer les lock, les index, etc comme il faut).

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: décidément on commence à avoir du choix

                Posté par (page perso) . Évalué à  4 .

                Dans cette discussion je crois que l'on confond l'interface et l'implémentation:

                Un SGBD, c'est une implémentation plus ou moins complexe (SQLite vs. Postgre), avec une interface simple et élégante: le SQL
                Un système de fichiers, c'est une implémentation plus ou moins complexe (FAT vs. btrfs), avec une interface simple et élégante: la norme POSIX

                Ce sont deux systèmes assez différents pour stocker des données, chacun a une interface simple et une implémentation complexe.

                • [^] # Re: décidément on commence à avoir du choix

                  Posté par (page perso) . Évalué à  2 .

                  une interface simple et élégante: le SQL

                  Simple et élégant, le SQL ? Eh bé…

                  • [^] # Re: décidément on commence à avoir du choix

                    Posté par (page perso) . Évalué à  2 .

                    Qu'est-ce que tu lui reproches?

                    • [^] # Re:décidément on commence àavoir du choix

                      Posté par (page perso) . Évalué à  -2 .

                      Qu'est-ce que tu lui reproches?

                      impossible de faire un SELECT a,b,c,d, FROM table il y a une virgule en trop apres le d et à peu près le meme probleme sur les autres clauses.

                      • [^] # Re:décidément on commence àavoir du choix

                        Posté par . Évalué à  2 . Dernière modification : le 20/03/13 à 18:15

                        Tu n'a pas plus pertinent comme argument ? (je vais t'aider la norme qui est très mal respectée par exemple ce qui nuit fortement à l’interopérabilité)

                        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                        • [^] # Re:décidément on commence àavoirdu choix

                          Posté par (page perso) . Évalué à  4 .

                          Tu n'a pas plus pertinent comme argument ? (je vais t'aider la norme qui est très mal respectée par exemple ce qui nuit fortement à l’interopérabilité)

                          la norme qui est tres mal respectée c'est le probleme de l'implementation pas du langage.

                          • [^] # Re:décidément on commence àavoirdu choix

                            Posté par . Évalué à  5 .

                            C'est pas faux.

                            Mais pour ce dont tu parlais, trouve-tu que les langages qui ne supportent les appels de méthodes avec des , en trop ne sont pas élégant ? Personnellement je ne vois pas bien l'intérêt de pouvoir écrire :

                            foo(a, b, c, d,);
                            
                            

                            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                            • [^] # Re:décidément on commence àavoirduchoix

                              Posté par (page perso) . Évalué à  2 .

                              Quand tu fais ça toute la journée, tu en as un peu ras le bol de pas pouvoir faire de copier coller, ou d'inserer un truc en fin de select sans oublié de rajouter une virgule avant. Meme punition pour les AND dans les commandes, resultat pendant ma phase de debut j'ai souvent un SELECT col1,col2,"fin" FROM bla WHERE 1 AND x AND y etc.

                              • [^] # Re:décidément on commence àavoirduchoix

                                Posté par . Évalué à  3 .

                                Ouai personnellement, ça ne m'a jamais dérangeais, même quand à l'IUT on faisait des sessions de 4h de requêtage intensif. Tout comme lorsque je passe ma nuitjournée à programmer et que je dois systématiquement avoir le bon nombre de virgule dans l'appel de chacune de mes fonctions. Je trouve au contraire que ce serait bien dommage d'inclure ce genre de bizarreries juste pour permettre d'écrire de manière un peu plus moche (comme le C++ l'a fait avec les enum par exemple).

                                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: décidément on commence à avoir du choix

        Posté par (page perso) . Évalué à  3 .

        il y a aussi NWS :
        http://linuxfr.org/users/coin--2/journaux/google-reader-se-moque#comment-1436824
        https://github.com/xaccrocheur/nws

        « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: décidément on commence à avoir du choix

        Posté par . Évalué à  1 .

        Merci de m'avoir fait découvrir kriss-feed ! Ca sera parfait pour mon sheevaplug (ARM,512Mo).
        Les données sont stockées dans un gros fichier PHP. Je pense qu'une petite base SQLite pourrait être une évolution sympa…

        Par contre, je sais pas vous, mais le scrolling a tendance à "sauter" tout seul dans mon firefox mobile. A suivre…

  • # importation

    Posté par (page perso) . Évalué à  1 .

    ça a l'air sympa et je voudrais tester mais l'importation du fichier opml de mon Tiny Tiny RSS ne fonctionne pas : "Unable to import your OPML file." (même en enlevant le …)

    <?xml version="1.0" encoding="utf-8"?>
    <opml version="1.0">
      <head>
        <dateCreated>Tue, 19 Mar 2013 10:21:06 +0000</dateCreated>
        <title>Tiny Tiny RSS Feed Export</title>
      </head>
      <body>
        <outline text="coding">
          <outline text="La Ferme du web" xmlUrl="http://feeds.lafermeduweb.net/LaFermeDuWeb" htmlUrl="http://www.lafermeduweb.net"/>
          <outline text="Planète jQuery" xmlUrl="http://feeds.feedburner.com/PlaneteJqueryFr" htmlUrl="http://planete-jquery.fr"/>
        </outline>
      </body>
    </opml>
    
    

    Une piste peut-être?

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: importation

      Posté par (page perso) . Évalué à  2 .

      Je suis intéressé aussi, j'ai pas pu importer mes flux depuis TTRSS, ni de Leed.

      • [^] # Re: importation

        Posté par (page perso) . Évalué à  2 .

        Mouais, PicoFeed a l'air vraiment "pico", aucun test de validité des éléments qu'il parse, du coup si il manque des attributs XML t'es bien baisé.

      • [^] # Re: importation

        Posté par . Évalué à  1 .

        Essai de virer l'accent.

    • [^] # Re: importation

      Posté par (page perso) . Évalué à  1 .

      Je vais corriger ca dans les jours qui viennent. C'est juste un problème de jeunesse du projet.

      En effet, actuellement les tests unitaires sont loin de couvrir tous les cas à 100%, mais je vais améliorer tout ca.

    • [^] # Re: importation

      Posté par (page perso) . Évalué à  3 .

      J'ai réussi en ajoutant à la main les attributs description, type, et title et en supprimant les dossiers.

      Un truc qui passe:

      <?xml version="1.0" encoding="utf-8"?>
      <opml version="1.0">
        <body>
          <head>
              <title>RSS</title>
          </head>
              <outline text="0xjfdube" xmlUrl="http://jfdube.wordpress.com/feed/" htmlUrl="http://jfdube.wordpress.com"  type="rss" description="" title=""/>
              <outline text="250bpm-blogs" xmlUrl="http://www.250bpm.com/feed/pages/pagename/blog/category/blog/t/250bpm-blogs/h/http%3A%2F%2Fwww.250bpm.com%2Fblog" htmlUrl="http://www.250bpm.com/blog"  type="rss" description="" title="" />
        </body>
      </opml>
      
      
      • [^] # Re: importation

        Posté par (page perso) . Évalué à  1 .

        effectivement, merci j'ai pu tester c'est minimaliste, les catégories ça manque un peu quand même.
        Pour ceux qui ont peu de flux et la possibilité d'utiliser sqlite c'est pas mal.

        Pour plus de flux : très léger et sans base de données KriSS Feed

        Sinon j'aime beaucoup Tiny Tiny RSS mais c'est plus lourd il faut une base de données.

        wind0w$ suxX, GNU/Linux roxX!

  • # Pas de gestion des catégories

    Posté par (page perso) . Évalué à  6 .

    La gestion des catégories est quand même indispensable à mes yeux, dommage sinon Miniflux semble très intéressant par sa légèreté

  • # Mot de passe admin vide

    Posté par . Évalué à  2 .

    J'ai installé miniflux mais le mot de passe admin est vide dans la base sqlite :

    sqlite> select * from config;
    admin||15
    
    

    Je ne trouve par pourquoi mais je ne lis pas le PHP couramment et les logs sont vides.

    • [^] # Re: Mot de passe admin vide

      Posté par (page perso) . Évalué à  2 .

      le login c'est admin, le mot de passe c'est admin aussi.

      Visiblement le mot de passe (par défaut du moins) est stocké dans schema.php:

      ./schema.php: VALUES ('".\PicoTools\Crypto\password_hash('admin')."')

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Mot de passe admin vide

        Posté par . Évalué à  1 .

        Merci, j'avais lu la doc ;-). Sauf que le champ est vide dans la base de données et je ne peux pas me connecter.

        • [^] # Re: Mot de passe admin vide

          Posté par (page perso) . Évalué à  2 .

          ok, c'est bizarre, essaye de tout réinstaller, j'imagine que la base est initialisée à la première connexion, car effectivement chez moi j'ai cela :

          sqlite> select * from config;
          admin|$2y$10$1sjRss09h7jW4ErjuqE56el5bHGiCErjeJBPa//NGKzuxevs7IRKu|15
          
          

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

    • [^] # Re: Mot de passe admin vide

      Posté par (page perso) . Évalué à  1 .

      En fait c'est un bug avec PHP < 5.3.7. Je n'ai pas encore pu reproduire le bug car je n'ai pas de vieille version de PHP sous la main.

      Cependant, j'ai fait un quick and dirty fix à l'aveugle sans tester dans la branche master.

      Pour plus d'informations, ce bug est suivi ici : https://github.com/fguillot/miniflux/issues/2

  • # c'est parti pour essayer ça

    Posté par . Évalué à  1 .

    j'utilise leed depuis quelques temps maintenant mais Miniflux me semble bien sympa, je vais l'essayer pendant un moment.
    J'avoue que j'utilise de temps en temps les catégories pour retrouver un flux mais je verrai bien si je survis sans.
    L'installation simple comme ça est vraiment top en tout cas.

    • [^] # Re: c'est parti pour essayer ça

      Posté par (page perso) . Évalué à  1 .

      testé et presque adopté, j'ai juste un souci d'affichage de caractères qui donne :

      catastrophe, plus moyen d’accéder à la bêteâ,

      au lieu de :

      catastrophe, plus moyen d'€™accéder à la bête,

      Si quelqu'un à une piste, je suis preneur…

  • # Sympa, mais trop light

    Posté par . Évalué à  5 .

    J'aime la minimaliste light de Miniflux, mais la pour le coup, c'est trop light : pas de catégorie, pas de gestion de lu / non lu article par article.
    Je reste sur Leed pour le moment, même si je ne le trouve pas très stable.

    • [^] # Re: Sympa, mais trop light

      Posté par . Évalué à  1 .

      Je n'aime pas les réseaux sociaux à la Facebook ou Google+. Il n'y a donc aucune forme de partage, d'envoi par email ou encore de système de favoris.

      Vu la simplicité du truc, une petite option pour sauvegarder le lien dans son shaarli serait sympa, ces logiciels sont complémentaires

  • # Sympa

    Posté par (page perso) . Évalué à  1 .

    Pas mal, j'aime beaucoup la philosphie et le design. Avec quelques modifications mineures on devrait même pouvoir en faire un agrégateur public (type Planet) correct. Pas fan de l'AGPL, mais bon, c'est le choix de l'auteur…

    • [^] # Re: Sympa

      Posté par . Évalué à  2 .

      Pas fan de l'AGPL, mais bon, c'est le choix de l'auteur…

      Qu'est-ce qui ne te plait pas dans l'AGPL ?

      • [^] # Re: Sympa

        Posté par (page perso) . Évalué à  2 .

        Bah, c'est une licence compliquée, et je ne suis pas avocat. Les notions d'œuvre dérivée et d'agrégat sont floues et les interprétations varient selon les juridictions. Donc j'évite simplement d'utiliser du logiciel AGPL s'il y a la moindre chance que ça contamine quelque chose d'autre que je fais.

        Si j'utilise Miniflux normalement, pas de problème, mais si je le modifie pour en faire un agrégateur et que je l'inclus dans un site, que se passe-t-il ? Je dois distribuer les modifications du code de Miniflux, mais mon site est-il un agrégat ou un programme ? Ai-je le droit d'alimenter le Planet depuis le champ "blog" des profils d'un forum dont la licence n'est pas compatible avec l'AGPL (comme par exemple la GPL v2…) ?

        Je n'essaie pas de faire du FUD, j'essaie de comprendre ce que je fais. L'AGPL est trop complexe pour que la majorité des gens qui l'utilisent la comprennent. En tout cas moi j'ai mis des années à comprendre les subtilités de la GPL, donc l'AGPL ce n'est pas pour tout de suite.

        Bref, de toute façon ce n'est pas un problème concret, à court terme je n'ai pas l'intention de publier un service qui utilise ce logiciel, licence ou pas.

    • [^] # Re: Sympa

      Posté par (page perso) . Évalué à  1 .

      Au départ, je ne savais pas quelle licence choisir, mais en allant sur ce site de comparaison : http://www.tldrlegal.com/license/gnu-affero-general-public-license-v3-(agpl-3.0)

      En lisant ceci :

      the AGPL is the GPL of the web

      Bah, hop vendu, ca sera AGPL.

  • # Clients natifs et centralisation

    Posté par . Évalué à  1 .

    J'avais l'habitude d'utiliser newsbeuter pour lire depuis différentes machines mes flux agrégés par Google Reader. Comme newsbeuter le supporte, ça fait un moment que je songe à remplacer Reader par TTRSS. Mais aujourd'hui j'hésite ; dur de mettre en balance le plaisir de pouvoir utiliser un outil simple totalement piloté par le clavier et l'envie de ne pas installer un truc aussi gros que TTRSS.

    Je cherche donc dans l'idéal un truc léger pour centraliser les flux sur mon site, assorti d'un moyen de les lire en dehors du navigateur (et du mobile). Est-ce que certains d'entre vous ont résolu ce genre de dilemme ?

    • [^] # Re: Clients natifs et centralisation

      Posté par (page perso) . Évalué à  1 .

      Ce qui serait génial, ce serait un genre d'OPML, étendu pour indiquer les articles lus et non lus. Ça permettrait d'avoir un serveur très simple pour utilisation avec un logiciel dédié, surtout que c'est la mode en ce moment, d'avoir des logiciels dédiés pour tout et n'importe quoi.

      • [^] # Re: Clients natifs et centralisation

        Posté par (page perso) . Évalué à  6 .

        surtout que c'est la mode en ce moment, d'avoir des logiciels dédiés pour tout et n'importe quoi.

        Et moi qui croyait que c'était un des "principes" unix d'avoir un outil pour chaque problématique.

      • [^] # Re: Clients natifs et centralisation

        Posté par (page perso) . Évalué à  2 .

        Le futur lecteur de flux rss d'owncloud aura aussi un protocole pour synchroniser les flux avec Akregator (et sûrement d'autres…).

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Clients natifs et centralisation

        Posté par (page perso) . Évalué à  3 .

        Je sais pas… Mes 400+ flux dans un OPML font déjà près de 150 ko, s'il faut rajouter les informations pour chaque item et se les échanger entre tous ses appareils, ça risque de faire une grosse consommation de bande passante. À la limite, uniquement les éléments non-lus, pourquoi pas, mais garder la liste complète pour l'échanger continuellement me parait vraiment inimaginable.

        • [^] # Re: Clients natifs et centralisation

          Posté par (page perso) . Évalué à  4 .

          Les éléments non lus connus ainsi que les éventuels éléments plus récents lus. Autrement dit, les états exacts, lus ou non lus, de tous les messages situés dans la zone frontière entre le « j'ai tout lu » et « je n'ai encore rien lu ».

          En particulier, cela permettrait de ne pas noter les états des messages plus anciens, considérés comme lus — sinon ils seraient notés comme non lus — et de ceux plus récents, considérés comme non lus — sinon ils seraient notés comme lus.

          Genre :

            1  lu
            2  lu
            3  lu
          n 4  non lu
          n 5  non lu
          l 6  lu
            7  non lu
            8  non lu
            9  non lu
           10 non lu
          
          

          Inutile de préciser pour les autres éléments.

  • # Tous les liens s'ouvrent dans un nouvel onglet

    Posté par . Évalué à  3 .

    Tous les liens s'ouvrent dans un nouvel onglet

    Quel intérêt ? Personnellement, j'apprécie décider au cas par cas si je suis un lien dans l'onglet actif ou s'il faut que le navigateur ouvre un onglet. J'utilise un « clic molette » pour cela et je trouve très désagréable le fameux « target=_blank » qui décide à la place de l'utilisateur.

    Pour modérer un peu mes propos, je dois bien reconnaître que j'ouvre toujours les articles de mon agrégateur dans de nouveaux onglets, mais tout de même, je n'aime pas que ce soit fait automatiquement.

    Sinon, j'adore ton projet. Chaque fonctionnalité est louable pour son bon sens. Bravo !

  • # et vous avez quoi contre Liferea ou Akregator?

    Posté par . Évalué à  1 .

    cela dit, j'aime beaucoup le rendu de ton lecteur.

    • [^] # Re: et vous avez quoi contre Liferea ou Akregator?

      Posté par (page perso) . Évalué à  4 .

      Bah juste que sur deux machines différentes (boulot/maison), il n'y a pas de synchronisation de ce qui est déjà lu sur l'autre machine.

      It's a fez. I wear a fez now. Fezes are cool !

    • [^] # Re: et vous avez quoi contre Liferea ou Akregator?

      Posté par (page perso) . Évalué à  1 .

      J'ai absolument rien contre les applis desktop. C'est simplement que pour mon usage je préfère une version web. Comme ca je peux lire mes flux depuis plusieurs machines avec différents OS (au travail sous Linux, à la maison sous OSX ou depuis n'importe où sans rien synchroniser…).

  • # simple et trés efficace

    Posté par . Évalué à  2 .

    Merci beaucoup, j'aime beaucoup, c'est simple et très efficace

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.