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).
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.
Aller plus loin
- Site officiel (2167 clics)
- Dépôt Git (353 clics)
# Service en ligne
Posté par fredix . Évalué à 10. Dernière modification le 19 mars 2013 à 11:02.
Bravo pour ton
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 0xfg . É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 CrEv (site web personnel) . Évalué à 10.
Sérieux ? Il y a des gens qui l'utilisent ?
[^] # Re: Service en ligne
Posté par gUI (Mastodon) . Évalué à 8. Dernière modification le 19 mars 2013 à 18:59.
Apparemment il y en a au moins un qui essaie de les refourguer !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Service en ligne
Posté par pmoret (site web personnel) . Évalué à 0.
Moi qui pensais que le bitcoin y'en a plus rien valoir du tout…
[^] # Re: Service en ligne
Posté par fredix . Évalué à 2.
Il vient d'atteindre 50$ l'unité : https://mtgox.com
# décidément on commence à avoir du choix
Posté par jeekajoo (site web personnel) . Évalué à 10.
j'en oublie surement, vive le libre :)
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
Et quand on n'aime pas les serveurs de bases de données :
[^] # Re: décidément on commence à avoir du choix
Posté par jeekajoo (site web personnel) . Évalué à 3.
RSSMiner utilise MySQL comme datastore.
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ah, mince. Un de moins.
[^] # Re: décidément on commence à avoir du choix
Posté par JoeltheLion (site web personnel) . Évalué à 5.
Tu as quoi contre les serveurs de bases de données?
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 19 mars 2013 à 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 barmic . Évalué à 6.
Personnellement j'attends un peu plus :
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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.
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 2PetitsVerres . Évalué à 1.
Wikipédia dit :
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
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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . É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 Batchyx . Évalué à 5.
Et ça passe à l'échelle à 30 000 articles ?
[^] # Re: décidément on commence à avoir du choix
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
ls et cat sur des répertoires contenant 30.000 fichiers ? Oui.
[^] # Re: décidément on commence à avoir du choix
Posté par JoeltheLion (site web personnel) . Évalué à 4.
Mais c'est bien moins efficace qu'une select sur une base de données SQL.
[^] # Re: décidément on commence à avoir du choix
Posté par oinkoink_daotter . Évalué à 5.
Sans compter que ça doit offrir une gestion intéressante des problèmes de concurrence …
[^] # Re: décidément on commence à avoir du choix
Posté par vlamy (site web personnel) . É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 fravashyo . Évalué à 6.
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 barmic . Évalué à 4.
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.
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.
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é.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: décidément on commence à avoir du choix
Posté par JoeltheLion (site web personnel) . É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 barmic . Évalué à 2.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:décidément on commence àavoir du choix
Posté par Juke (site web personnel) . Évalué à 2.
Pas forcement.
[^] # Re:décidément on commence àavoir du choix
Posté par barmic . É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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:décidément on commence àavoirdu choix
Posté par Juke (site web personnel) . Évalué à 2.
Comme les droits des fichiers.
je ne connaissais pas deby merci.
[^] # Re:décidément on commence àavoirdu choix
Posté par CrEv (site web personnel) . Évalué à 2.
Derby non ? http://db.apache.org/derby/
[^] # Re:décidément on commence àavoirdu choix
Posté par barmic . Évalué à 2.
Oui faute de frappe.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:décidément on commence àavoirdu choix
Posté par barmic . Évalué à 2.
Tu dois de toute manière la gérer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: décidément on commence à avoir du choix
Posté par JoeltheLion (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Simple et élégant, le SQL ? Eh bé…
[^] # Re: décidément on commence à avoir du choix
Posté par JoeltheLion (site web personnel) . Évalué à 2.
Qu'est-ce que tu lui reproches?
[^] # Re:décidément on commence àavoir du choix
Posté par Juke (site web personnel) . Évalué à -2.
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 barmic . Évalué à 2. Dernière modification le 20 mars 2013 à 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é)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:décidément on commence àavoirdu choix
Posté par Juke (site web personnel) . Évalué à 4.
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 barmic . É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 :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re:décidément on commence àavoirduchoix
Posté par Juke (site web personnel) . É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 barmic . É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).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: décidément on commence à avoir du choix
Posté par fravashyo . É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 nomorsad . É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 i M@N (site web personnel) . É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 …)
Une piste peut-être?
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: importation
Posté par Gui13 (site web personnel) . Évalué à 2.
Je suis intéressé aussi, j'ai pas pu importer mes flux depuis TTRSS, ni de Leed.
[^] # Re: importation
Posté par Gui13 (site web personnel) . É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 FabienC . Évalué à 1.
Essai de virer l'accent.
[^] # Re: importation
Posté par 0xfg . É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 Gui13 (site web personnel) . Évalué à 3.
J'ai réussi en ajoutant à la main les attributs
description
,type
, ettitle
et en supprimant les dossiers.Un truc qui passe:
[^] # Re: importation
Posté par i M@N (site web personnel) . É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 François LE QUEMENER (site web personnel) . É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 Flyinva . Évalué à 2.
J'ai installé miniflux mais le mot de passe admin est vide dans la base sqlite :
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 fravashyo . É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 Flyinva . É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 fravashyo . É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 :
« 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 0xfg . É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 gallarus . É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 Mali (site web personnel) . Évalué à 1.
testé et presque adopté, j'ai juste un souci d'affichage de caractères qui donne :
au lieu de :
Si quelqu'un à une piste, je suis preneur…
[^] # Re: c'est parti pour essayer ça
Posté par Mali (site web personnel) . Évalué à 1.
adopté, merci pour les mises à jour !
# Sympa, mais trop light
Posté par itoine . É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 Faya . Évalué à 1.
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 catwell (site web personnel) . É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 nomorsad . Évalué à 2.
Qu'est-ce qui ne te plait pas dans l'AGPL ?
[^] # Re: Sympa
Posté par catwell (site web personnel) . É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 0xfg . É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 :
Bah, hop vendu, ca sera AGPL.
# Clients natifs et centralisation
Posté par d_rol (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 CrEv (site web personnel) . Évalué à 6.
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 ariasuni . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Pitié, pas encore une API de plus, faites un truc standard à vocation indépendante…
[^] # Re: Clients natifs et centralisation
Posté par ariasuni . Évalué à 4.
Ça m'étonnerait, la communauté derrière KDE sont connus pour suivre les standards, et comme pour l'instant il n'existe rien…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Clients natifs et centralisation
Posté par rakoo (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . É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 :
Inutile de préciser pour les autres éléments.
# Tous les liens s'ouvrent dans un nouvel onglet
Posté par philou . Évalué à 3.
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 !
[^] # Re: Tous les liens s'ouvrent dans un nouvel onglet
Posté par Gui13 (site web personnel) . Évalué à 0.
Pour un ordi portable, c'est plus sympa (pas de clic molette).
[^] # Re: Tous les liens s'ouvrent dans un nouvel onglet
Posté par ariasuni . Évalué à 2.
Ctrl Clic?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tous les liens s'ouvrent dans un nouvel onglet
Posté par Nonolapéro . Évalué à 2.
Ou tapotage avec deux doigts si ton pavé tactile est sympa.
[^] # Re: Tous les liens s'ouvrent dans un nouvel onglet
Posté par ariasuni . Évalué à -1.
C'est pas un peu acrobatique/aléatoire?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Tous les liens s'ouvrent dans un nouvel onglet
Posté par philou . Évalué à 1.
Il a mille solutions (voir la suite de la conversation) que je trouve plus sympathiques que de forcer l'ouverture de la page dans un nouvel onglet. Quitte à y être, on pourra ajouter le « clic droit / ouvrir dans un onglet ». Selon la configuration de son navigateur, je crois même qu'il est possible de donner le focus au lien survolé et d'utiliser ensuite le bouton « menu contextuel » du clavier. Enfin bref, je préfère toutes ces solutions à la désagréable solution de forcer l'ouverture d'un nouvel onglet.
Pour moi, c'est aussi une question d'ergonomie. Je préfère parcourir mes flux, ouvrir tout ce qui est susceptible de m'intéresser (sans quitter l'onglet en cours) et seulement après passer d'onglet en onglet pour lire l'article.
# et vous avez quoi contre Liferea ou Akregator?
Posté par Mme Michu-cide . Évalué à 1.
cela dit, j'aime beaucoup le rendu de ton lecteur.
[^] # Re: et vous avez quoi contre Liferea ou Akregator?
Posté par Framasky (site web personnel) . É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.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: et vous avez quoi contre Liferea ou Akregator?
Posté par 0xfg . É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 sileht . Évalué à 2.
Merci beaucoup, j'aime beaucoup, c'est simple et très efficace
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.