Diaspora est loin d'être le seul réseau social Libre, ni le plus avancé, ni rien du tout en fait. Son seul avantage […] c'est d'avoir fait beaucoup de bruit autour de son financement.
Si je suis d'accord que techniquement, Diaspora* est à la ramasse il a quand même un truc en plus et c'est justement lié au fait qu'il ait fait "du bruit" : les utilisateurs. N'en déplaise au troll récurrent "ah bon, Diaspora* n'est pas mort ?" (cf. le premier commentaire), il y a une base d'utilisateurs qui est assez conséquente et qui continue de s'agrandir. La communauté francophone est d'ailleurs très active. Je pense que c'est un avantage non négligeable sur les autres.
Pour être clair : pour moi Diaspora* est un réseau social de passage / de transition en attendant LA solution qui me plaira techniquement et qui saura fédérer une bonne base d'utilisateurs. Ce qui explique par ailleurs que je n'ai pas la foi de contribuer à D* plus que ça si ce n'est venir le défendre sur LinuxFR ;)
Disaspora* aurait pu avoir le meilleur protocole du monde, je suis désolé mais y a trop de lacunes.
Diaspora* aurait eu le meilleur protocole du monde, les fonctionnalités que tu demandes seraient là. J'ai toujours critiqué le choix qu'ils ont fait à ce niveau-là, mais c'est trop tard. Il y a eu des discussions pour passer à XMPP mais je crois que ce n'était qu'une idée en l'air qui n'aboutira pas.
Je répète ce que j'ai dit plus haut : tout le monde a conscience qu'il y a un manque de fonctionnalités et qu'il y a des bugs (la fédération des pods reste bancale notamment), mais les développeurs font avec ce qu'ils ont (ressources et temps). Au moins des gens se sont bougés les fesses pour tenter de faire quelque chose. Ta critique a été entendue, mais ce qui passe mal c'est qu'une bonne partie de ton journal sous-entend que Diaspora* a été développé avec les pieds et que tu es capable de faire mieux. On attend de voir :)
J'ai un peu réfléchis sur une manière d'unifier un réseau et je pense qu'il faut créer impérativement créer une API.
C'est ce que je pensais : tu as une vision idéalisée et naïve de comment développer un réseau social. Premièrement, ce n'est pas une API qu'il te faut, c'est un protocole. Ton histoire d'API, et tu le dis toi même, est impensable à grande échelle. Ta solution est donc de créer un réseau social centralisé. Bah oui sauf que non, le but de Diaspora* c'est de décentraliser au maximum (même si tout n'est pas rose) ! Quand tu dis :
On peut aussi imaginer un serveur décentraliser, mais cela demanderait encore plus de travail et n'intéresserait pas vraiment les gens.
Tu serais surpris de voir le nombre de personnes qui recherche ça. Si ton annuaire tombe, comment il fonctionne ton réseau ?
Donc forcément, si tu enlèves la grosse épine de difficulté qui est aussi la clé de voûte de D* (la décentralisation), c'est plus simple… Sauf que tu ne réponds pas à la volonté de base.
Bref, contrairement à d'autres, si tu y tiens, je t'encourage à développer ton réseau social. Par contre ça ne servira à rien si tu te lances tout seul dans ton coin sans prendre en compte les problématiques auxquelles ont été confrontés tes prédécesseurs. Le mieux est de venir en discuter sur D*, ou avec Goffi de SàT, ou avec d'autres, mais surtout arrêter de dire "je ne comprends pas pourquoi les autres font de la merde, moi je peux faire mieux avec un framework PHP", c'est à côté de la plaque et tu sous-estimes grandement le travail des autres.
Attention, je suis juste utilisateur moi :p Mais je suis quand même d'assez prêt D* parce que ça m'intéresse.
Pour les libs, Friendica (PHP) est capable de communiquer avec donc y a peut-être moyen de gratter de ce côté. Mais comme tu fais du Python, je te conseille de regarder du côté de Diaspy (https://github.com/marekjm/diaspy). Ce n'est pas très fonctionnel mais une partie du protocole a été implémenté et de mémoire c'était séparé. Si tu as besoin de plus je peux faire remonter, il me semble qu'il y avait autre chose en Python.
on pense d'abord aux fonctions que l'on souhaite y intégrer.
On pense surtout à tout un tas de choses comme les fonctionnalités, comment on va les intégrer, quels sont les problèmes qui vont se poser (au hasard, la recherche dans un réseau décentralisé). Tout un tas de choses que le projet Diaspora* n'a pas suffisamment pris en compte au départ, oui. Le problème c'est que ce sont les 4 développeurs de départ qui n'avaient pas les épaules / compétences pour gérer ça. Et ils ont eu une telle visibilité médiatique qu'il y a eu énormément de déçus. Alors heureusement des gens ont été là pour les aider, mais ils ont quand même abandonné.
Des fois je me dis que le mieux serait de tout casser pour tout reconstruire. Mais de façon plus pragmatique, la priorité reste de documenter correctement le protocole et le stabiliser (éventuellement le revoir / simplifier tout en restant compatible avec l'actuel : grosse difficulté). Ensuite, procurer les librairies qui vont bien en PHP / Python / Ruby / etc. pour qu'un maximum de gens puissent construire un environnement autour, compatible avec le logiciel de base. Le must serait de créer des ponts avec XMPP pour communiquer avec des projets comme Sàt, Movim ou Jappix.
j'aimerais bien y apporter ma contribution, mais je n'ai pas le temps ni la motivation d'apprendre le ruby
Si je te rejoins sur un certain nombre de points, je tiens à faire quelques précisions :
Les développeurs sont peu nombreux et sont, bien sûr, bénévoles. La masse de code à gérer est assez énorme de ce que j'ai compris et tous ne sont pas aptes à modifier les parties les plus compliquées / cachées. Actuellement ils se concentrent, il me semble, à séparer la partie "protocole" du reste du code pour en faire une gem (langage Ruby, je pense que ça représente grosso modo une librairie) à part.
Mettre en confrontation PHP et Ruby (ou Python d'ailleurs) commence à m'énerver. Ok tout le monde ne connait pas Ruby, mais je pense qu'objectivement ça reste un bon langage (je dis ça alors que je suis plutôt Python et avant PHP). À l'inverse, je pense que le PHP est plus sujet à discussion au niveau de sa qualité. Laissons / laissez les développeurs choisir le langage qu'ils préfèrent / connaissent le mieux. J'ai horreur de l'excuse "oui mais PHP est plus répandu alors ils devraient développer en PHP". Le langage n'est pas une fin en soit !
Pour le manque de fonctionnalités, nous sommes tous d'accord, les développeurs les premiers. Comme je le disais, ils sont peu nombreux et ne bossent pas H24 dessus. Le chat est censé arriver prochainement si tout va bien, l'album photo est noté "à faire" quelque part.
Je ne vois pas trop ce que tu as à reprocher à "l'application Android" (qui n'est qu'une vue responsive de la version web). Je la trouve au contraire très fonctionnelle pour ce qu'elle est censée faire (bien plus que ce qui existe pour FB par exemple).
J'aurais bien des critiques à faire (choix du protocole que personne ne connaît / comprend et difficulté d'installation notamment). Mais la plupart des choses que tu pointes est clairement un manque de moyen et les développeurs de Diaspora seraient très heureux d'avoir des coups de main externes :)
Pour finir :
je ne comprends pas comment un tel logiciel pourrait rencontrer du succès
Et pourtant, il y a une communauté francophone assez importante et pas uniquement des geeks. Je suis le premier à dire que D* n'a pas d'avenir mais force est de constater qu'il a quand même rencontré son public. Ce ne sont pas toujours les meilleurs solutions techniques qui réussissent mais souvent celles qui ont (eu) le plus de visibilité médiatique.
Tu peux passer par StartSSL qui propose des certificats reconnus gratuits pour un domaine + un sous-domaine. Il y a CACert aussi qui fonctionne un peu différemment (communautaire toussa toussa) mais qui n'est pas aussi bien reconnu par les navigateurs.
Par contre je suis absolument contre le certificat auto-signé. D'un point de vue utilisateur, c'est vraiment catastrophique: les gens prennent l'habitude d'accepter n'importe quoi, ce qui abaisse la sécurité globale.
Entièrement d'accord avec toi ! Si au moins la mise en place était bien faite, je ne dis pas, mais quand on me demande d'accepter un certificat auto-signé pour lire un article de blog, pour le moment je regarde si je peux y accéder en HTTP mais un de ces jours je ne ferais même plus cet effort.
Perso, j'ai mis en place un certificat (au début auto-signé) que j'utilise uniquement pour la partie administration : c'est le mien, je sais la tête qu'il doit avoir. Le reste du site / blog est en accès par HTTP par défaut. Mais maintenant que j'ai un certificat certifié par StartSSL je continue de même parce que j'en ai marre de cette paranoïa. C'est un peu comme si je devais me déguiser avec un chapeau, des lunettes de soleil, une fausse moustache et un long manteau noir pour aller voir mon voisin… je trouve ça aberrant (mais j'ai bien conscience que c'est parfois nécessaire vu les excès en matière d'espionnage, DPI, etc.).
De plus, si la mise en place d'un certificat est facile pour un domaine, ça commence à devenir galère pour du multi-domaine avec des sous-domaines dans tous les sens…
Je suis un peu tiraillé par la question du HTTPS. Si en soit c'est une bonne idée, j'ai l'impression que depuis Snowden on tombe dans une sorte de paranoïa (peut-être justifiée ?) où chaque page web DOIT être accessible en HTTPS. C'est souvent utile certes, mais dans le cas d'un petit site perso j'ai du mal à y voir un grand intérêt (mise à part la zone d'administration). La dernière fois que j'ai écrit un article là-dessus, on m'a fait remarquer (avec raison) que HTTPS a deux fonctions :
Chiffrer les échanges (dans le cas d'un petit blog je trouve l'intérêt très limité)
Identifier un site pour s'assurer qu'il est bien celui qu'il dit être. Problème ? Souvent les gens se contentent d'un certificat auto-signé. Du coup pourquoi devrais-je faire confiance à ce certificat ? On pourrait très bien essayer de me faire accepter n'importe quoi… Le pire étant quand on me force à l'accepter car pas d'accès HTTP (généralement je quitte simplement la page)
Donc voilà : je m'interroge sur l'intérêt du HTTPS dans certains cas, encore plus quand on nous demande (ou force !) d'accepter un certificat auto-signé…
J'ai coché PHP parce que c'est ce que j'ai le plus pratiqué, mais je me mets doucement au Python : j'ai un peu joué avec Bottle et je me suis amusé avec le tuto de Django dans l'optique d'un futur projet.
Ben s'il suffit d'avoir des stocks épuisés pour être un succès, c'est simple, il suffit de prévoir un stock miniscule.
C'est pas comme ça que font les autres ?</semi-troll>
Alors si en plus si on décourage les Early Adopters avec ce genre de bévues…
Oui sauf que ce téléphone est prévu pour les développeurs : il n'est pas prévu pour les Early Adopters, encore moins pour les utilisateurs finaux (la RAM qui est "bridable" notamment, quel intérêt sur un téléphone grand public ?).
Après je fais preuve de mauvaise foi (et sans doute Mozilla aussi un peu) car je sais bien que, forcément, les gens même non-développeurs vont vouloir se jeter dessus. Mais Mozilla n'a jamais menti sur la marchandise et je considère qu'on ne peut pas leur en vouloir de ne pas avoir prévu les stocks pour Nb_Utilisateurs * Nb_Développeurs.
On peut noter aussi que Mozilla est sur un créneau un peu particulier puisqu'ils visent les pays émergents avec des téléphones bas de gamme mais que paradoxalement, la plus grand attente provient des pays plus riches.
Sinon moi je m'en fous : j'ai pu le pré-commander \o/
Plus sérieusement, pour la 1.3, le GPS et le problème des minuscules ok, mais le fait que tu n'aies ni Hangout ni Skype ne me pose franchement aucun problème. C'est comme se plaindre de ne pas avoir des applications spécifiques iPhone sous Android (et vice-versa)
Pour les majs pas simple je suis d'accord, ils auraient dû rendre le système plus simple. Après peut-être qu'il s'agit d'un soucis au niveau de ZTE qui n'a pas joué le jeu et pas fourni les mises à jour (c'est ce que je comprends à la lecture personnellement). J'ai pré-commandé le Flame, officiellement supporté par Mozilla, je pourrai toujours faire un retour pour voir si ça se passe mieux ;)
Mais l'argument "Adoptez un nouveau moteur ; bon, il est tout pourri, mais on est gentils" est bidon.
Il est bidon pour ceux qui se fichent de leur vie privée ou si c'est le seul argument.
Gnu/Linux est intéressant entre autre parce qu'il est Libre.
Si Firefox a envahi les bureaux, ce n'est pas parce qu'il est Libre, mais le fait qu'il soit Libre est clairement un argument valable (principale raison pour laquelle je ne suis pas passé à Chrome ou Opera).
Mais je te rejoins sur l'idée de base : on ne conquiert pas un marché sur le seul argument "mon logiciel est Libre / mon service ne vous traque pas". L'éthique seule ne paye pas et ne sert même pas à grand chose.
Qu'est-ce qu'un non-informaticien ? La question sous-entend que tous les "non-informaticiens" possèdent les mêmes besoins, or dans mon entourage je vais en avoir :
qui n'en ont rien à foutre tant que ça marche et que c'est gratuit
qui vont être sensibilisé à l'éthique du logiciel Libre
qui recherchent des fonctionnalités poussées
qui cherchent à se protéger de la surveillance généralisée
Bref, autant de besoins différents qui vont engendrer des critères de choix différents. La catégorie "non informaticien" est bien trop imprécise pour que l'on puisse répondre.
Sinon on peut voir la question sous un autre angle. Si c'est l'argument du "c'est un logiciel Libre" qui fait que la personne va le choisir au détriment d'un logiciel privateur, alors je ne vois plus qu'une réponse possible : le côté éthique du Libre et la liberté qui va avec car, fondamentalement, c'est tout ce que promet le logiciel Libre (ce n'est ni une question de fonctionnalités, ni de prix, ni de sécurité… ce que "vend" le mouvement open source en gros)
Il y a vaguement un message au premier lancement pour nous rappeler que c'est du torrent, et donc pas très légal, mais on peut ensuite oublier toute la technique sous-jacente.
Est-ce totalement compatible avec l'API de feedly ?
J'avoue ne pas trop savoir ce qu'il en est, mais d'après les discussions que j'ai pu voir passer les deux API ne sont pas compatibles non… Une proposition avait été de supporter plusieurs API différentes histoire d'être compatible le plus largement possible. Personnellement je pense que c'est une perte de temps : FreshRSS n'est toujours pas en version 1.0 et de toute manière, être compatible sans pouvoir changer de serveur niveau client, ça ne sert pas à grand chose.
Ça pourrait être chouette oui :) Par contre je viens de jeter un coup d'œil, ils ne proposent un accès qu'à NewsBlur, The Old Reader et Feedly. Il faudrait leur demander d'ajouter une option pour pouvoir choisir son propre serveur. Je m'en occuperai durant le week-end je pense.
Je pense qu'il y a une vérification si, et je n'ai pas vraiment envie de m'amuser à ce genre de chose de toutes manières ;)
Pour ce qui est du fichier /etc/hosts ça ne me parait pas plus envisageable car il faut que l'on pointe (actuellement du moins) sur une URL bien définie (http://mon.serveur/freshrss/p/greader.php). Du coup la redirection va marcher au niveau IP mais pas au niveau du chemin… quoique y a peut-être moyen de se débrouiller quand même à ce niveau-là. Mais bon, ce qui serait cool c'est de lancer un mouvement qui fait que les lecteurs mobiles de flux RSS ne dépendent plus d'un serveur en particulier. C'est du gagnant-gagnant puisque les applis pourraient se remettre à marcher pour n'importe qui a un agrégateur compatible API Google Reader et qu'en plus ça nous permet de vendre FreshRSS comme possédant une foultitude de lecteurs mobiles.
[^] # Re: Petite idée
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 2.
Si je suis d'accord que techniquement, Diaspora* est à la ramasse il a quand même un truc en plus et c'est justement lié au fait qu'il ait fait "du bruit" : les utilisateurs. N'en déplaise au troll récurrent "ah bon, Diaspora* n'est pas mort ?" (cf. le premier commentaire), il y a une base d'utilisateurs qui est assez conséquente et qui continue de s'agrandir. La communauté francophone est d'ailleurs très active. Je pense que c'est un avantage non négligeable sur les autres.
Pour être clair : pour moi Diaspora* est un réseau social de passage / de transition en attendant LA solution qui me plaira techniquement et qui saura fédérer une bonne base d'utilisateurs. Ce qui explique par ailleurs que je n'ai pas la foi de contribuer à D* plus que ça si ce n'est venir le défendre sur LinuxFR ;)
[^] # Re: red#matrix
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 6.
Diaspora* aurait eu le meilleur protocole du monde, les fonctionnalités que tu demandes seraient là. J'ai toujours critiqué le choix qu'ils ont fait à ce niveau-là, mais c'est trop tard. Il y a eu des discussions pour passer à XMPP mais je crois que ce n'était qu'une idée en l'air qui n'aboutira pas.
Je répète ce que j'ai dit plus haut : tout le monde a conscience qu'il y a un manque de fonctionnalités et qu'il y a des bugs (la fédération des pods reste bancale notamment), mais les développeurs font avec ce qu'ils ont (ressources et temps). Au moins des gens se sont bougés les fesses pour tenter de faire quelque chose. Ta critique a été entendue, mais ce qui passe mal c'est qu'une bonne partie de ton journal sous-entend que Diaspora* a été développé avec les pieds et que tu es capable de faire mieux. On attend de voir :)
[^] # Re: red#matrix
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 10.
C'est ce que je pensais : tu as une vision idéalisée et naïve de comment développer un réseau social. Premièrement, ce n'est pas une API qu'il te faut, c'est un protocole. Ton histoire d'API, et tu le dis toi même, est impensable à grande échelle. Ta solution est donc de créer un réseau social centralisé. Bah oui sauf que non, le but de Diaspora* c'est de décentraliser au maximum (même si tout n'est pas rose) ! Quand tu dis :
Tu serais surpris de voir le nombre de personnes qui recherche ça. Si ton annuaire tombe, comment il fonctionne ton réseau ?
Donc forcément, si tu enlèves la grosse épine de difficulté qui est aussi la clé de voûte de D* (la décentralisation), c'est plus simple… Sauf que tu ne réponds pas à la volonté de base.
Bref, contrairement à d'autres, si tu y tiens, je t'encourage à développer ton réseau social. Par contre ça ne servira à rien si tu te lances tout seul dans ton coin sans prendre en compte les problématiques auxquelles ont été confrontés tes prédécesseurs. Le mieux est de venir en discuter sur D*, ou avec Goffi de SàT, ou avec d'autres, mais surtout arrêter de dire "je ne comprends pas pourquoi les autres font de la merde, moi je peux faire mieux avec un framework PHP", c'est à côté de la plaque et tu sous-estimes grandement le travail des autres.
[^] # Re: Quelques mots à propos de D*
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 2.
Je rajouterai aussi (même si ça reste infime) qu'il y a les coups matériels. A priori, le serveur qui fait tourner le pod "principal" coute un bras.
[^] # Re: Quelques mots à propos de D*
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 3.
Attention, je suis juste utilisateur moi :p Mais je suis quand même d'assez prêt D* parce que ça m'intéresse.
Pour les libs, Friendica (PHP) est capable de communiquer avec donc y a peut-être moyen de gratter de ce côté. Mais comme tu fais du Python, je te conseille de regarder du côté de Diaspy (https://github.com/marekjm/diaspy). Ce n'est pas très fonctionnel mais une partie du protocole a été implémenté et de mémoire c'était séparé. Si tu as besoin de plus je peux faire remonter, il me semble qu'il y avait autre chose en Python.
[^] # Re: Quelques mots à propos de D*
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 5.
Nous sommes d'accord ;)
On pense surtout à tout un tas de choses comme les fonctionnalités, comment on va les intégrer, quels sont les problèmes qui vont se poser (au hasard, la recherche dans un réseau décentralisé). Tout un tas de choses que le projet Diaspora* n'a pas suffisamment pris en compte au départ, oui. Le problème c'est que ce sont les 4 développeurs de départ qui n'avaient pas les épaules / compétences pour gérer ça. Et ils ont eu une telle visibilité médiatique qu'il y a eu énormément de déçus. Alors heureusement des gens ont été là pour les aider, mais ils ont quand même abandonné.
Des fois je me dis que le mieux serait de tout casser pour tout reconstruire. Mais de façon plus pragmatique, la priorité reste de documenter correctement le protocole et le stabiliser (éventuellement le revoir / simplifier tout en restant compatible avec l'actuel : grosse difficulté). Ensuite, procurer les librairies qui vont bien en PHP / Python / Ruby / etc. pour qu'un maximum de gens puissent construire un environnement autour, compatible avec le logiciel de base. Le must serait de créer des ponts avec XMPP pour communiquer avec des projets comme Sàt, Movim ou Jappix.
Une seule chose à répondre à ça (si tu lis l'anglais) : https://diaspora-fr.org/posts/595580
Et les développeurs initiaux connaissaient le Ruby, la boucle est bouclée :)
# Quelques mots à propos de D*
Posté par berumuron . En réponse au journal Diaspora bien tenté mais.... Évalué à 10.
Si je te rejoins sur un certain nombre de points, je tiens à faire quelques précisions :
J'aurais bien des critiques à faire (choix du protocole que personne ne connaît / comprend et difficulté d'installation notamment). Mais la plupart des choses que tu pointes est clairement un manque de moyen et les développeurs de Diaspora seraient très heureux d'avoir des coups de main externes :)
Pour finir :
Et pourtant, il y a une communauté francophone assez importante et pas uniquement des geeks. Je suis le premier à dire que D* n'a pas d'avenir mais force est de constater qu'il a quand même rencontré son public. Ce ne sont pas toujours les meilleurs solutions techniques qui réussissent mais souvent celles qui ont (eu) le plus de visibilité médiatique.
[^] # Re: Ça calcule vite mais ça met du temps à communiquer
Posté par berumuron . En réponse au journal Total s'appuie sur un super-calculateur tournant sous Linux !. Évalué à 4.
C'est parce que tu n'as pas cliqué sur le lien…
[^] # Re: Mensonges !
Posté par berumuron . En réponse au journal Journal-nimage rapidoce en deuspi tavu. Évalué à 1.
Bin en Creuse aussi on a des bonnets rouges, et pourtant on ne parle ni de vache, ni de bonnet rouge, ni de cochon, ni même d'ornithorynque !
# Mensonges !
Posté par berumuron . En réponse au journal Journal-nimage rapidoce en deuspi tavu. Évalué à 0.
Tu n'as pas parlé des vaches ! Y a plein de vaches en Creuse ! J'suis sûr que t'es à Paris, c'est un peu la même niveau hostilité !
[^] # Re: Idem, pour mon premier site web, tout est en HTTPS
Posté par berumuron . En réponse au journal Passer au HTTPS pour améliorer son PageRank. Évalué à 2.
Tu peux passer par StartSSL qui propose des certificats reconnus gratuits pour un domaine + un sous-domaine. Il y a CACert aussi qui fonctionne un peu différemment (communautaire toussa toussa) mais qui n'est pas aussi bien reconnu par les navigateurs.
[^] # Re: Noui…
Posté par berumuron . En réponse au journal Passer au HTTPS pour améliorer son PageRank. Évalué à 2.
Entièrement d'accord avec toi ! Si au moins la mise en place était bien faite, je ne dis pas, mais quand on me demande d'accepter un certificat auto-signé pour lire un article de blog, pour le moment je regarde si je peux y accéder en HTTP mais un de ces jours je ne ferais même plus cet effort.
Perso, j'ai mis en place un certificat (au début auto-signé) que j'utilise uniquement pour la partie administration : c'est le mien, je sais la tête qu'il doit avoir. Le reste du site / blog est en accès par HTTP par défaut. Mais maintenant que j'ai un certificat certifié par StartSSL je continue de même parce que j'en ai marre de cette paranoïa. C'est un peu comme si je devais me déguiser avec un chapeau, des lunettes de soleil, une fausse moustache et un long manteau noir pour aller voir mon voisin… je trouve ça aberrant (mais j'ai bien conscience que c'est parfois nécessaire vu les excès en matière d'espionnage, DPI, etc.).
De plus, si la mise en place d'un certificat est facile pour un domaine, ça commence à devenir galère pour du multi-domaine avec des sous-domaines dans tous les sens…
# Noui…
Posté par berumuron . En réponse au journal Passer au HTTPS pour améliorer son PageRank. Évalué à 2.
Je suis un peu tiraillé par la question du HTTPS. Si en soit c'est une bonne idée, j'ai l'impression que depuis Snowden on tombe dans une sorte de paranoïa (peut-être justifiée ?) où chaque page web DOIT être accessible en HTTPS. C'est souvent utile certes, mais dans le cas d'un petit site perso j'ai du mal à y voir un grand intérêt (mise à part la zone d'administration). La dernière fois que j'ai écrit un article là-dessus, on m'a fait remarquer (avec raison) que HTTPS a deux fonctions :
Donc voilà : je m'interroge sur l'intérêt du HTTPS dans certains cas, encore plus quand on nous demande (ou force !) d'accepter un certificat auto-signé…
# De plus en plus de Python
Posté par berumuron . En réponse au sondage Quel langage utilisez-vous sur vos serveurs pour vos applications web ?. Évalué à 1.
J'ai coché PHP parce que c'est ce que j'ai le plus pratiqué, mais je me mets doucement au Python : j'ai un peu joué avec Bottle et je me suis amusé avec le tuto de Django dans l'optique d'un futur projet.
[^] # Re: Qu'il marche?
Posté par berumuron . En réponse au journal Firefox OS, mon avis !. Évalué à 2.
Plus maintenant
[^] # Re: Qu'il marche?
Posté par berumuron . En réponse au journal Firefox OS, mon avis !. Évalué à 0.
C'est pas comme ça que font les autres ?</semi-troll>
Oui sauf que ce téléphone est prévu pour les développeurs : il n'est pas prévu pour les Early Adopters, encore moins pour les utilisateurs finaux (la RAM qui est "bridable" notamment, quel intérêt sur un téléphone grand public ?).
Après je fais preuve de mauvaise foi (et sans doute Mozilla aussi un peu) car je sais bien que, forcément, les gens même non-développeurs vont vouloir se jeter dessus. Mais Mozilla n'a jamais menti sur la marchandise et je considère qu'on ne peut pas leur en vouloir de ne pas avoir prévu les stocks pour Nb_Utilisateurs * Nb_Développeurs.
On peut noter aussi que Mozilla est sur un créneau un peu particulier puisqu'ils visent les pays émergents avec des téléphones bas de gamme mais que paradoxalement, la plus grand attente provient des pays plus riches.
Sinon moi je m'en fous : j'ai pu le pré-commander \o/
[^] # Re: Qu'il marche?
Posté par berumuron . En réponse au journal Firefox OS, mon avis !. Évalué à 5.
Tu leur reproches quoi au juste ? D'avoir eu plus de succès que prévu ? Je trouve justement que c'est un bon point pour eux…
[^] # Re: Qu'il marche?
Posté par berumuron . En réponse au journal Firefox OS, mon avis !. Évalué à 6.
(Intransitif) Se déplacer par un mouvement alternatif des jambes ou des pattes, en ayant toujours un appui au sol.
Source
Plus sérieusement, pour la 1.3, le GPS et le problème des minuscules ok, mais le fait que tu n'aies ni Hangout ni Skype ne me pose franchement aucun problème. C'est comme se plaindre de ne pas avoir des applications spécifiques iPhone sous Android (et vice-versa)
Pour les majs pas simple je suis d'accord, ils auraient dû rendre le système plus simple. Après peut-être qu'il s'agit d'un soucis au niveau de ZTE qui n'a pas joué le jeu et pas fourni les mises à jour (c'est ce que je comprends à la lecture personnellement). J'ai pré-commandé le Flame, officiellement supporté par Mozilla, je pourrai toujours faire un retour pour voir si ça se passe mieux ;)
[^] # Re: Méta-moteurs
Posté par berumuron . En réponse à la dépêche Se passer de Google, Facebook et autres big brothers 2.0 #1 — Les moteurs de recherche. Évalué à 5.
Il est bidon pour ceux qui se fichent de leur vie privée ou si c'est le seul argument.
Gnu/Linux est intéressant entre autre parce qu'il est Libre.
Si Firefox a envahi les bureaux, ce n'est pas parce qu'il est Libre, mais le fait qu'il soit Libre est clairement un argument valable (principale raison pour laquelle je ne suis pas passé à Chrome ou Opera).
Mais je te rejoins sur l'idée de base : on ne conquiert pas un marché sur le seul argument "mon logiciel est Libre / mon service ne vous traque pas". L'éthique seule ne paye pas et ne sert même pas à grand chose.
# Pas tellement de sens ?
Posté par berumuron . En réponse au sondage Quels sont les critères de choix pour adopter un logiciel libre pour un non informaticien ?. Évalué à 1.
Qu'est-ce qu'un non-informaticien ? La question sous-entend que tous les "non-informaticiens" possèdent les mêmes besoins, or dans mon entourage je vais en avoir :
Bref, autant de besoins différents qui vont engendrer des critères de choix différents. La catégorie "non informaticien" est bien trop imprécise pour que l'on puisse répondre.
Sinon on peut voir la question sous un autre angle. Si c'est l'argument du "c'est un logiciel Libre" qui fait que la personne va le choisir au détriment d'un logiciel privateur, alors je ne vois plus qu'une réponse possible : le côté éthique du Libre et la liberté qui va avec car, fondamentalement, c'est tout ce que promet le logiciel Libre (ce n'est ni une question de fonctionnalités, ni de prix, ni de sécurité… ce que "vend" le mouvement open source en gros)
# Plus d'infos…
Posté par berumuron . En réponse au journal DuckDuckGo change de parure. Évalué à 2.
À priori, aujourd'hui. Plus d'informations sur leur forum (https://duck.co/forum/thread/5726/duckduckgo-reimagined-and-redesigned) où l'on apprend qu'il y a aussi de nouvelles fonctionnalités et qu'il reste des bugs (normal
c'est une beta)[^] # Re: torret != illégal
Posté par berumuron . En réponse au journal Popcorn Time, la vidéo à la demande (presque) parfaite. Évalué à 10.
Il ne l'a peut-être pas dite, mais écrite oui…
[^] # Re: API
Posté par berumuron . En réponse au journal FreshRSS(-dev) fait copain-copain avec l'API Google Reader. Évalué à 3.
Il y en a une oui, pas officielle mais il me semble qu'Alkarex s'est basé sur cette page : https://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI
J'avoue ne pas trop savoir ce qu'il en est, mais d'après les discussions que j'ai pu voir passer les deux API ne sont pas compatibles non… Une proposition avait été de supporter plusieurs API différentes histoire d'être compatible le plus largement possible. Personnellement je pense que c'est une perte de temps : FreshRSS n'est toujours pas en version 1.0 et de toute manière, être compatible sans pouvoir changer de serveur niveau client, ça ne sert pas à grand chose.
[^] # Re: Super
Posté par berumuron . En réponse au journal FreshRSS(-dev) fait copain-copain avec l'API Google Reader. Évalué à 3.
Ça pourrait être chouette oui :) Par contre je viens de jeter un coup d'œil, ils ne proposent un accès qu'à NewsBlur, The Old Reader et Feedly. Il faudrait leur demander d'ajouter une option pour pouvoir choisir son propre serveur. Je m'en occuperai durant le week-end je pense.
[^] # Re: Hack
Posté par berumuron . En réponse au journal FreshRSS(-dev) fait copain-copain avec l'API Google Reader. Évalué à 4.
Je pense qu'il y a une vérification si, et je n'ai pas vraiment envie de m'amuser à ce genre de chose de toutes manières ;)
Pour ce qui est du fichier /etc/hosts ça ne me parait pas plus envisageable car il faut que l'on pointe (actuellement du moins) sur une URL bien définie (http://mon.serveur/freshrss/p/greader.php). Du coup la redirection va marcher au niveau IP mais pas au niveau du chemin… quoique y a peut-être moyen de se débrouiller quand même à ce niveau-là. Mais bon, ce qui serait cool c'est de lancer un mouvement qui fait que les lecteurs mobiles de flux RSS ne dépendent plus d'un serveur en particulier. C'est du gagnant-gagnant puisque les applis pourraient se remettre à marcher pour n'importe qui a un agrégateur compatible API Google Reader et qu'en plus ça nous permet de vendre FreshRSS comme possédant une foultitude de lecteurs mobiles.
Mais c'est gentil de proposer :)