La décentralisation totale est séduisante mais a ses inconvénients (complexité et/ou lenteur).
L'installation simple c'est une question de temps: les solutions populaires vont certainement être incluses dans les distributions, et la simplification des procédures se fait avec l'augmentation du nombre d'utilisateurs.
on en cite régulièrement, j'en ai rappelé quelques unes dans ce commentaire, il y en a aussi pas mal cités dans le wiki.
Maintenant il faut déjà se poser la question de ce que tu veux faire avec, les projets cités ont des niveaux de maturité différents, des implémentations différentes, des philosophie différentes. Si c'est pour le boulot, le choix du langage/des technologies d'implémentation peuvent être important si vous avez des modifs persos à faire.
Si c'est juste en interne, un truc centralisé comme Elgg (journal récent) peut sûrement convenir.
Pour la maîtrise des données, il est nécessaire d'héberger soit-même l'instance. Pour pouvoir utiliser plusieurs logiciels en même temps, XMPP est le meilleur (le seul ?) choix actuel: plusieurs projets tournent autour, et certains permettent déjà de faire beaucoup de choses MOVIM et Salut à Toi par exemple.
Pour Salut à Toi sur lequel je bosse, on espère avoir une version prête pour le grand public d'ici l'été prochain.
Tout dépend ce que tu appelles réseau « social ». Si c'est de l'étalage de vie privée, c'est plus la case voyeurisme (que j'ai plus mis pour troller qu'autre chose). Pour moi ce terme ne veut pas dire grand chose (pour ne pas dire rien), mais il y a des outils qu'on retrouve dans cette catégorie qui sont utiles: partager des photos facilement c'est possible avec un serveur HTTP maison, organiser des événements une simple page wiki peut le permettre (ou un framadate/framapad), mais avoir les 2 réunis et une interface facile d'accès c'est pratique.
Je suis étonné que pour l'instant partage de photo et organisation d'événements ont un pourcentage si faibles, je pense qu'avec l'outil de microblogage c'est l'usage le plus intéressant (le fait d'avoir les 3 réunis surtout, indépendamment ça se trouve déjà facilement).
Enfin bref, pour moi communiquer que la toile c'est justement l'intérêt principal.
Oui je suis d'accord, au moins pour certaines fonctionnalités. Avec XMPP, il est possible de s'authentifier de manière anonyme au moins pour le chat si le serveur l'autorise, Poezio le permet facilement par exemple.
Par ailleurs, il y a des gens qui ont des recommendations pour des logiciels libre de réseau sociaux décentralisés maintenus et qui ressemblent pas complètement à de la blague (pas forcément en terme de nombre d'utilisateurs) ?
Tout dépend de ce que tu attends de ce genre de trucs. Mais les trucs maintenus et qui ne sont pas des blagues, il commence à y en avoir quelques uns, on sort régulièrement des listes. De tête (mais j'en oublie): Retroshare, Friendica, Lorea, GNU Social - qui récupère le code de status.net -, et ceux plus ou moins basés sur XMPP; Buddycloud, Jappix, MOVIM et SàT. On va pouvoir ajouter Twister maintenant.
Ils sont à ma connaissance tous maintenus (pour GNU Social et Lorea c'est peut-être à confirmer), et plusieurs d'entre eux sont fonctionnels ou en passe de l'être. Ils sont tous là depuis plusieurs années (sauf Twister), et ils ont probablement tous besoin de contributeurs si vous voulez que ça aille plus vite.
En centralisé sur peux ajouter Elgg qui a eu le droit à un journal il y a quelques temps, et un bon paquet de projets de Forums/blogs/etc.
Bref, encore une fois, tout dépend de ce que tu attends de ce genre de choses…
Ah ben ça tombe bien, je viens justement de l'acheter.
C'est encore un peu tôt pour donner un avis pertinent, mais quelques remarques quand même.
J'ai déjà développé avec Qt4 mais relativement peu, en fait je m'y suis surtout mis il y a 2 ans pour une interface SàT que j'ai dû mettre en pause à cause de ma vie professionnelle. Du coup j'ai vu une mention de ce bouquin sur le net et je suis parti l'acheter en librairie.
Première remarque: c'est cher. Les bouquins d'infos sont souvent chers, mais là c'est la fourchette vraiment haute (65 € pour l'édition papier). Je prends un bouquin justement pour ne pas avoir à lire sur un écran (sinon j'aurais juste pris la doc officielle Qt), du coup les éditions numériques ne m'intéressent pas. Contrairement à ce qui est dit ici, la qualité d'impression me semble suffisante pour ce type de livre (d'après la réponse à ce commentaire, l'imprimeur a été changé depuis les premiers livres).
Comme indiqué, ça parle surtout de QML, ça tombe bien c'était ce que je voulais connaître principalement, vu que j'ai déjà des notions pour le reste. Il y a quand même quelques chapitres sur Qt Widgets, de quoi se rafraîchir la mémoire. En plus il y a un chapitre pour le passage Qt4 => Qt5. Par contre, je ne vois pas ce que la lecture « par module » change, dans n'importe quel bouquin on peut sauter les chapitres qu'on maîtrise déjà ou qui ne nous intéressent pas.
Ça évoque très rapidement des concepts de base pour de la programmation (très très basiquement la programmation orientée objets, ou des notions de bases de javascripts). Dans mon cas c'est totalement inutile, mais ça peut être intéressant pour filer le bouquin à des non programmeurs (c'est visiblement le but recherché).
Ça a l'air assez complet aussi: encore une fois je viens de commencer, mais ça parle de Qt Creator, Qt Designer, des outils de débogage, de la transition Qt4 => Qt5, etc. Enfin assez complet pour la partie interface graphique, ça ne parle pas ou très bièvement du reste du cadriciel, en introduction il est précisé que d'autres bouquins sont envisagés.
Bon dans mon cas, QML/Qt Quick a l'air très facile à assimiler (surtout que je connais déjà CSS, Javascript, les EFL et en particulier Edje dont QML s'inspire visiblement). Le prix est trop élevé mais le livre a l'air bien et surtout va me permettre de me remettre à jour en me sortant un peu la tête de ce satané écran…
Bon bref, on verra si à la fin de la lecture j'en suis toujours content, et c'est bien de voir de la presse francophone sur Qt…
Ce n'est pas compliqué, IBM date de 1924 comme nom pour cette entreprise quand le film révélant HAL n'était même pas encore un projet de son réalisateur !
Ou alors IBM a une machine temporelle pour rendre cela possible.
euh… Le fait que IBM ait été créé avant que Kubrick ne fasse 2001 l'Odyssée de l'espace me semble justement indispensable pour qu'il y ait une référence à IBM dans le film non ?
Par contre je crois que ça a été démenti par Kubrick lui-même, mais il faut reconnaître que la coïncidence si c'en est bien une est bien tombée.
Il n'a en effet pas été condamné à mort mais à la prison, et a souhaité la castration chimique à la place, et il aurait été empoisonné en mangeant une pomme (d'aucuns y voient l'origine du logo d'apple même si ça a été démenti - tout comme d'aucuns voient en HAL les lettres IBM même si ça a été démenti, l'informatique a quelques histoires croustillantes du style - ).
À noter aussi que son opinion sur l'intelligence artificielle a fait grincer quelques dents.
C'est pas mal de rappeler ce genre de choses de nos jours… Même si les mœurs ont changées, pas sûr que l'homosexualité soit si bien acceptée aujourd'hui.
Je ne comprends pas ce que certains ont contre asm.js, je trouve l'idée excellente: des optimisations que tous les navigateurs peuvent implémenter, sans perdre la compatibilité avec l'existant.
Il est évident que ce n'est pas fait pour coder directement, dart n'est pas comparable (et en suivant de loin ça a l'air intéressant aussi, je n'ai rien contre dart et à mon avis ça ne s'oppose pas du tout à asm.js). Ça n'est pas non plus fait pour coder en C++ pour le web (faudrait être un peu maso), mais ça peut servir pour porter des choses utiles (par exemple sqlite a été porté ainsi, ça peut-être intéressant de l'utiliser en javascript).
Pour moi c'est plus la possibilité d'avoir une machine virtuelle native, et ainsi de coder dans le langage qu'on veut, ça se rapproche plus d'une vm java sans la complication des plugins à installer.
Et l'argument de Mozilla de ne pas vouloir maintenir 2 langages me semble tout à fait valable.
Pour ma part je code l'interface web de SàT en Python qui est ensuite compilé en Javascript avec Pyjamas: ça me permet d'utiliser un langage que je préfère, et de factoriser une bonne partie du code (un gain de temps très appréciable). asm.js est dans cet esprit et ça me paraît être une bonne direction.
La gestion de version est aussi intéressante pour les données et c'est plus simple d'avoir tout au même endroit.
Oui j'entends bien, je parlais de séparer dans un autre dépôt. Ça rend le dépôt de code moins lourd (télécharger les binaires à chaque clone, c'est un peu relou et pas cool pour le serveur), et les médias bougent moins souvent a priori (même pour un jeu). Pour SàT le backend est dans sat, les médias sans sat_media: http://repos.goffi.org/
La gestion de version est bien utile pour les binaires aussi, je suis d'accord.
Pourquoi avoir lâché fossil, toi qui n'arrêtais pas d'en faire la louange ?
Sinon pourquoi ne pas séparer les données du code ? Ça évide d'avoir un dépôt trop lourd tout en les versionnant. C'est ce qu'on fait pour SàT: d'un côté les médias, et de l'autre le code (mais on a évidemment beaucoup moins de fichiers binaires que pour un jeu). Mercurial s'en sort pas trop mal, m'étonne que ça ne soit pas le cas pour git.
Bon aujourd'hui je suis très pressé, donc je n'ai pas trop le temps de répondre individuellement (y'a beaucoup de commentaires !), aussi je réponds à quelques points rapidement ici:
pourquoi vous imaginez que SàT va être difficile à installer ? Le seul argument (valable) qu'à PHP en face c'est que ça tourne sur des dédiés pré-installés qui souvent ne fournissent que PHP, mais à part ça SàT devrait être très facile à installer, même plus que la plupart des autres vu qu'il intègre son propre serveur web et il n'y aura donc pas de serveur web à installer/configurer. sur une Debian, en gros une installation avec le serveur ça devrait ressembler d'ici l'été prochain à (en root): # apt-get install prosody sat-xmpp-libervia, puis configuration de Prosody (quelques minutes, c'est vraiment facile) et éventuellement quelques autres minutes à configurer 2 bricoles sur SàT (ports à utiliser par exemple). Si vous avez déjà un compte/serveur XMPP, c'est comme installer n'importe quel autre client. J'ai mis Prosody en exemple, mais ça peut être un autre serveur bien sûr.
il n'y a pas besoin d'un serveur particulier qui gère le microblogage ou autre. Nous utilisons notre propre composant Pubsub prévu pour fonctionner avec n'importe quel serveur, il y a juste quelque bricoles qui manquent dans les standards (en particulier la notion de composant privilégié pour pouvoir accéder au roster d'une entité pour ceux qui connaissent XMPP), mais ça n'est qu'une question de temps. Un des buts de XMPP c'est justement de ne pas rester bloquer à un serveur particulier.
Prosody est très bon, je ne comprends pas les critiques à son égard, c'est le serveur qu'on utilise principalement pour les tests, et on n'a jusqu'ici rien eu à lui redire.
XMPP marche entre différents clients pour d'autres choses que juste envoyer du texte, je ne comprends pas pourquoi tu dis ça devnewton ! Le transfert de fichier, les commandes ad-hoc, pubsub, jingle, etc tout ça marche d'un client à un autre. Le microblogage lui est encore en cours d'élaboration, encore une fois un peu de patience.
nous (SàT) n'avons jamais cherché (pour le moment) à avoir des utilisateurs, nous sommes encore en développement et on répète à tous ceux qui veulent essayer « ça n'est pas encore prêt pour la production, uniquement à titre expérimental, bla bla », je me suis même fait reprocher le dernier coup sur DLFP de trop insister là dessus. Ceux qui parlent d'échec ou de stratégie marketing ou que sais-je d'autre n'ont tout simplement pas compris ça. Là on envisage d'avoir une première version grand public d'ici l'été prochain, et ça me semble aujourd'hui réaliste.
Bon pour le reste j'ai d'autre choses à dire, mais je suis très pris en ce moment. Nous avons une 0.4 en préparation qu'on espère sortir avant la fin de l'année, j'en profiterai pour expliquer un peu les (gros) changement récents, et ce qu'on envisage pour l'avenir. RDV probablement un peu avant Noël.
Je n'ai jamais regardé les offres d'emploi ailleurs que sur Lolix, et c'est là que j'ai trouvé mes 2 boulots (2 CV envoyés la première fois, le seul CV envoyé la deuxième). C'était pour moi la garantie d'au minimum pouvoir bosser avec des technos libres. Je pense même qu'il était assez bien vu de la part des recruteurs d'avoir des candidatures venant de Lolix (ça montre des gens intéressés au libre, qui ont souvent une certaine culture technique associée).
On a choisi XMPP (qui a ses qualités et ses défauts) justement pour pouvoir travailler sur une base commune, qui est déjà suffisamment extensible pour permettre tout ce qu'on veut.
Les autres projets ont choisi de faire leur propre protocole, c'est à mon avis une erreur, mais ils ont leur raisons. Je ne sais pas s'ils ont l'intention de standardiser leurs trucs respectifs (j'imagine qu'ils ont tous l'espoir de devenir suffisamment populaires qu'ils deviennent des standards de fait, mais peut-être que je me trompe).
Enfin bref, de mon point de vue, XMPP a déjà toutes les qualités pour être le « posix » de la communication (mais y'a encore du boulot pour le microblogage).
Le choix de PHP ça peut être stratégique, ou tout simplement parce que c'est le langage que les dév à l'origine d'un projet connaissent le mieux. Pour Movim je sais que c'était stratégique: pouvoir être facilement installable y compris sur un serveur mutualisé (qui fournissent presque toujours un PHP plus ou moins récent). D'autres ont fait d'autres choix (Diaspora c'est Ruby, Newebe* et nous c'est Python), question de goût/point de vue. En tout cas je ne regrette pas une seconde d'être parti sur Python :)
En tout cas, je ne serai pas contre voir un planet dédié à ce genre d'outils, et des réunions de temps en temps…
*P.-S.: honte sur moi j'ai oublié de citer Newebe tout à l'heure !
On est en réflexion dessus, on a plusieurs possibilités envisagées, mais j'en parlerai un peu plus tard dans une dépêche, vu qu'on a une version sur le feu.
On utilise XMPP qui est un standard reconnu, on peut considérer ça comme du « posix ».
On a un backend qui gére toute la partie métier, y compris les extensions, et différents frontaux qui gèrent l'affichage (le tout communicant par un IPC, D-Bus actuellement). On fait en sorte qu'il soit le plus facile/rapide possible de faire un nouveau frontal, et de ne pas être dépendant de technos graphiques (nouvelle techno = nouveau frontal, mais ça consiste surtout à lier les appels D-Bus au comportement graphique adapté).
En gros, ça ressemble à ça:
Maintenant ce qui est demandé ici, c'est de pouvoir étendre l'interface par un utilisateur (je comprends ça comme « mon microblogage s'affiche de telle façon, j'aimerais ajouter un bouton/une image/un schmilblick qui affiche tel code HTML et qui fait tel truc »), soit un truc typiquement graphique.
Or nos frontaux utilisent des environnements graphiques complètement différents:
Libervia est un frontal web, il sort du XHTML
Wix est un frontal WxPython, il sort du WxWidgets
jp est un frontal cli, il sort du texte
Primitivus est un frontal console, il sort de l'Urwid (interface console à la ncurses)
Bellaciao est un frontal Qt et en C++, il sort du Qt
Bref, le bouton à ajouter qui sort un code XHTML ne peut être utilisable que pour Libervia.
Par contre, notre système d'extensions côté backend permet de sortir une interface avec un code XML (une sorte de micro-XUL) qui sera interprété par tous les frontaux ou presque, donc pour les cas simples on peut faire un truc commun.
Bref on essaye de factoriser au maximum, mais il y a des cas où c'est très dépendant de la techno d'affichage, d'où l'intérêt des interfaces multiples, et le probable besoin à terme de faire des extensions liées aux interfaces.
compatibles entre les frontaux tu veux dire ?
Ben vu que les frontaux peuvent être écrits en n'importe quel language (la plupart sont en Python, on en a un en C++ pour le moment), et avec n'importe quelles bibliothèques, ça me parait compromis.
Les extensions côté backend sont déjà utilisables par tous les frontaux, et elles sont capables d'afficher des interfaces.
Et j'ai pas l'impression salt (enfin l'ui web) & co utilise une architecture prévu pour que chaque bout de l'interface soit modifiable via une extension.
salt = SàT ? Dans ce cas non en effet, pour le moment les extensions sont uniquement côté backend, mais ça permet déjà de faire beaucoup de choses (à part les RFC de base et quelques XEPs principales, tout est fait sous forme d'extensions), et surtout ça profite à tous les frontaux d'un coup.
À terme si le besoin s'en fait sentir (ça sera probablement le cas au moins pour Libervia, le frontal web), on fera un système d'extensions aussi dans certains frontaux.
Attention, je parlais de l'état de fonctionnement actuel des réseaux sociaux distribués, je ne voulais pas que cela soit pris comme du: c'est de la merde ;)
Je ne l'ai pas pris comme ça, et quand bien même je suis ouvert à la critique (enfin si on y met les formes quand même), donc faut pas hésiter, c'est toujours bon d'avoir des retours :)
Pour Movim, je veux bien croire que y'a du boulot autour mais de ce que j'ai pu tester, c'est vraiment trop buggé… Et je parle même pas de ma tentative perso mais bien des pods indiqués sur le site. Et en particulier l'interface web manque vraiment d'une IHM plus claire parce que même moi, je voyais pas ou se trouvaient les zones de saisie de texte.
Bon là faudrait voir directement avec les dévs
Pour SalutAtoi, je savais que tu allais réagir :)
Ben oui, faut bien que je justifie mon temps sur DLFP au lieu de bosser sur SàT…
Mais dans l'ensemble, ce que je leur reproche, c'est le manque de fonctionnalités et je comprend du boulot que représente le dev d'un réseau distribué.
Nous sommes désormais 2 à plein temps sur SàT, et si tout va bien d'ici l'été prochain on devrait avoir une version installable facilement qui offre au minimum microblogage, partage de fichiers, organisation d'événements et chiffrage de bout en bout.
On a une 0.4 qui devrait sortir avant la fin de l'année…
Movim: Très buggé et surtout lent et sans les fonctionnalités essentielles pour espérer remplacer un Facebook ou G+
T'as rapporté les bogues à l'équipe de dév ? Timothée bosse beaucoup dessus et avance bien, si tu aides en faisant des rapports de bogues bien comme il faut, m'étonnerait qu'ils restent très longtemps tes bogues.
Salutatoi: Très geek, trop geek et surtout si j'ai bien compris, pas moyen d'intégrer ça sur un serveur web…
Bon là c'est pour moi: pourquoi trop geek ? Y'a des fonctionnalités console et tout oui, parce que ça ne fait pas que du microblogage et apparentés, mais l'interface web est prévue pour le grand public, même si elle est encore trop complexe (on y travaille). De toute façon ce n'est pas encore considéré grand public, on prévoit ça d'ici l'été prochain (ça sera la première version nommée).
Et sinon bien sûr que c'est intégrable à un serveur web. Libervia (l'interface web) a son propre serveur web intégré, mais il suffit de faire un reverse proxy sur Apache/Nginx ou autre et c'est réglé.
Oui c'est connu comme projet, et bien que je n'ai jamais essayé je pense pas mal. Mais c'est centralisé, ce n'est pas ce que nous (Movim, SàT, autre) on cherche. Il est nettement plus simple (et donc plus rapide) de faire un réseau centralisé, d'où son avance apparente. Si ça te convient, ben c'est parfait :).
Sinon as tu jeté un œil à Buddycloud, Friendica, Lorea, le fork de Diaspora (dont j'ai oublié le nom), pump.io, Gnu Social/StatusNet/Free social et Tent ?
Wé enfin Freenet ça existe depuis un sacré bout de temps, bien avant Twitter d'ailleurs. C'est un réseau pseudo-anonyme (basé sur un logiciel libre) qui permet d'accéder à des choses comme des sites ou des newsgroups. En plus de l'anonymat il permet la résistance à la censure (tant qu'un contenu est demandé, il est présent dans le réseau, plus il est demandé, plus il est facile à accéder), et la possibilité d'avoir de l'espace disponible sans serveur central (si je mets un fichier d'1 Go et qu'il est demandé, une fois qu'il est inséré sur le réseau je n'ai plus à me soucier de la place nécessaire pour l'héberger). C'est un projet très intéressant qui souffre(ait?) surtout d'une lenteur insupportable.
Darknet ça fait pas mal d'années que j'entends ce mot. Ça reste un terme pour renommer l'existant comme l'informatique aime bien en sortir régulièrement, et c'est probablement ce que Zimmermann a voulu dire dans l'entretien (même si je ne suis pas du tout d'accord avec sa façon de le dire). À ce moment là il serait à placer aux côtés de web 2.0, réseaux sociaux, cloud, etc.
J'ai écouté les 10 première minutes, pour Zimmermann un Darknet c'est « la capacité à 2 ordinateurs de parler le protocole de leur choix, que ça soit chiffré ou anonymisé n'y change rien » ou « internet moins le web ». D'après Wikipédia (francophone et anglophone) c'est bien anonymisé, et c'est la définition que j'ai toujours comprise. Ils ajoutent la notion d'ami à ami (F2F), là du coup c'est moins évident, puisque Freenet première version ne serait pas un Darknet.
À écouter Zimmermann (enfin à moins que j'ai mal compris) XMPP ou FTP c'est du Darknet. À lire Wikipédia, Freenet première version n'est pas un Darknet, TOR ça ne rentre pas dedans non plus. Guiton a l'air plus proche de la définition Wikipédia.
Je pense qu'un Retroshare mettra tout le monde d'accord :)
Du coup va falloir accorder les violons, est-ce qu'il y a une définition « officielle » quelque part ? Ça reste de la pignole, je trouve quand même plus clair de parler de réseau pseudo-anonyme, ou de réseau chiffré, etc.
Enfin je vais écouter la suite, mais pour le moment je ne suis pas convaincu du tout par Zimmermann.
[^] # Re: le social sur internet deviens aussi important que le social IRL
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à 4.
La décentralisation totale est séduisante mais a ses inconvénients (complexité et/ou lenteur).
L'installation simple c'est une question de temps: les solutions populaires vont certainement être incluses dans les distributions, et la simplification des procédures se fait avec l'augmentation du nombre d'utilisateurs.
[^] # Re: il existe quoi en alternative libre?
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à 4.
on en cite régulièrement, j'en ai rappelé quelques unes dans ce commentaire, il y en a aussi pas mal cités dans le wiki.
Maintenant il faut déjà se poser la question de ce que tu veux faire avec, les projets cités ont des niveaux de maturité différents, des implémentations différentes, des philosophie différentes. Si c'est pour le boulot, le choix du langage/des technologies d'implémentation peuvent être important si vous avez des modifs persos à faire.
Si c'est juste en interne, un truc centralisé comme Elgg (journal récent) peut sûrement convenir.
Pour la maîtrise des données, il est nécessaire d'héberger soit-même l'instance. Pour pouvoir utiliser plusieurs logiciels en même temps, XMPP est le meilleur (le seul ?) choix actuel: plusieurs projets tournent autour, et certains permettent déjà de faire beaucoup de choses MOVIM et Salut à Toi par exemple.
Pour Salut à Toi sur lequel je bosse, on espère avoir une version prête pour le grand public d'ici l'été prochain.
[^] # Re: Ma vie Privée ne regarde pas les autres
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à 3.
Tout dépend ce que tu appelles réseau « social ». Si c'est de l'étalage de vie privée, c'est plus la case voyeurisme (que j'ai plus mis pour troller qu'autre chose). Pour moi ce terme ne veut pas dire grand chose (pour ne pas dire rien), mais il y a des outils qu'on retrouve dans cette catégorie qui sont utiles: partager des photos facilement c'est possible avec un serveur HTTP maison, organiser des événements une simple page wiki peut le permettre (ou un framadate/framapad), mais avoir les 2 réunis et une interface facile d'accès c'est pratique.
Je suis étonné que pour l'instant partage de photo et organisation d'événements ont un pourcentage si faibles, je pense qu'avec l'outil de microblogage c'est l'usage le plus intéressant (le fait d'avoir les 3 réunis surtout, indépendamment ça se trouve déjà facilement).
Enfin bref, pour moi communiquer que la toile c'est justement l'intérêt principal.
[^] # Re: La non authentification?
Posté par Goffi (site web personnel, Mastodon) . En réponse au sondage Qu'attendez vous le plus d'un réseau dit « social » libre ?. Évalué à 4.
Oui je suis d'accord, au moins pour certaines fonctionnalités. Avec XMPP, il est possible de s'authentifier de manière anonyme au moins pour le chat si le serveur l'autorise, Poezio le permet facilement par exemple.
[^] # Re: there is an ap^Wxkcd for that
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Une étude prédit la disparition de Facebook en 2017. Évalué à 5.
Tout dépend de ce que tu attends de ce genre de trucs. Mais les trucs maintenus et qui ne sont pas des blagues, il commence à y en avoir quelques uns, on sort régulièrement des listes. De tête (mais j'en oublie): Retroshare, Friendica, Lorea, GNU Social - qui récupère le code de status.net -, et ceux plus ou moins basés sur XMPP; Buddycloud, Jappix, MOVIM et SàT. On va pouvoir ajouter Twister maintenant.
Ils sont à ma connaissance tous maintenus (pour GNU Social et Lorea c'est peut-être à confirmer), et plusieurs d'entre eux sont fonctionnels ou en passe de l'être. Ils sont tous là depuis plusieurs années (sauf Twister), et ils ont probablement tous besoin de contributeurs si vous voulez que ça aille plus vite.
En centralisé sur peux ajouter Elgg qui a eu le droit à un journal il y a quelques temps, et un bon paquet de projets de Forums/blogs/etc.
Bref, encore une fois, tout dépend de ce que tu attends de ce genre de choses…
# ah bah
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Créer des applications avec Qt 5. Évalué à 10.
Ah ben ça tombe bien, je viens justement de l'acheter.
C'est encore un peu tôt pour donner un avis pertinent, mais quelques remarques quand même.
J'ai déjà développé avec Qt4 mais relativement peu, en fait je m'y suis surtout mis il y a 2 ans pour une interface SàT que j'ai dû mettre en pause à cause de ma vie professionnelle. Du coup j'ai vu une mention de ce bouquin sur le net et je suis parti l'acheter en librairie.
Première remarque: c'est cher. Les bouquins d'infos sont souvent chers, mais là c'est la fourchette vraiment haute (65 € pour l'édition papier). Je prends un bouquin justement pour ne pas avoir à lire sur un écran (sinon j'aurais juste pris la doc officielle Qt), du coup les éditions numériques ne m'intéressent pas. Contrairement à ce qui est dit ici, la qualité d'impression me semble suffisante pour ce type de livre (d'après la réponse à ce commentaire, l'imprimeur a été changé depuis les premiers livres).
Comme indiqué, ça parle surtout de QML, ça tombe bien c'était ce que je voulais connaître principalement, vu que j'ai déjà des notions pour le reste. Il y a quand même quelques chapitres sur Qt Widgets, de quoi se rafraîchir la mémoire. En plus il y a un chapitre pour le passage Qt4 => Qt5. Par contre, je ne vois pas ce que la lecture « par module » change, dans n'importe quel bouquin on peut sauter les chapitres qu'on maîtrise déjà ou qui ne nous intéressent pas.
Ça évoque très rapidement des concepts de base pour de la programmation (très très basiquement la programmation orientée objets, ou des notions de bases de javascripts). Dans mon cas c'est totalement inutile, mais ça peut être intéressant pour filer le bouquin à des non programmeurs (c'est visiblement le but recherché).
Ça a l'air assez complet aussi: encore une fois je viens de commencer, mais ça parle de Qt Creator, Qt Designer, des outils de débogage, de la transition Qt4 => Qt5, etc. Enfin assez complet pour la partie interface graphique, ça ne parle pas ou très bièvement du reste du cadriciel, en introduction il est précisé que d'autres bouquins sont envisagés.
Bon dans mon cas, QML/Qt Quick a l'air très facile à assimiler (surtout que je connais déjà CSS, Javascript, les EFL et en particulier Edje dont QML s'inspire visiblement). Le prix est trop élevé mais le livre a l'air bien et surtout va me permettre de me remettre à jour en me sortant un peu la tête de ce satané écran…
Bon bref, on verra si à la fin de la lecture j'en suis toujours content, et c'est bien de voir de la presse francophone sur Qt…
[^] # Re: Alan Turing gracié
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Alan Turing gracié.. Évalué à 10.
euh… Le fait que IBM ait été créé avant que Kubrick ne fasse 2001 l'Odyssée de l'espace me semble justement indispensable pour qu'il y ait une référence à IBM dans le film non ?
Par contre je crois que ça a été démenti par Kubrick lui-même, mais il faut reconnaître que la coïncidence si c'en est bien une est bien tombée.
[^] # Re: Alan Turing gracié
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Alan Turing gracié.. Évalué à 6. Dernière modification le 25 décembre 2013 à 01:39.
Il n'a en effet pas été condamné à mort mais à la prison, et a souhaité la castration chimique à la place, et il aurait été empoisonné en mangeant une pomme (d'aucuns y voient l'origine du logo d'apple même si ça a été démenti - tout comme d'aucuns voient en HAL les lettres IBM même si ça a été démenti, l'informatique a quelques histoires croustillantes du style - ).
À noter aussi que son opinion sur l'intelligence artificielle a fait grincer quelques dents.
C'est pas mal de rappeler ce genre de choses de nos jours… Même si les mœurs ont changées, pas sûr que l'homosexualité soit si bien acceptée aujourd'hui.
[^] # Re: asm.js...
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 6.
Je ne comprends pas ce que certains ont contre asm.js, je trouve l'idée excellente: des optimisations que tous les navigateurs peuvent implémenter, sans perdre la compatibilité avec l'existant.
Il est évident que ce n'est pas fait pour coder directement, dart n'est pas comparable (et en suivant de loin ça a l'air intéressant aussi, je n'ai rien contre dart et à mon avis ça ne s'oppose pas du tout à asm.js). Ça n'est pas non plus fait pour coder en C++ pour le web (faudrait être un peu maso), mais ça peut servir pour porter des choses utiles (par exemple sqlite a été porté ainsi, ça peut-être intéressant de l'utiliser en javascript).
Pour moi c'est plus la possibilité d'avoir une machine virtuelle native, et ainsi de coder dans le langage qu'on veut, ça se rapproche plus d'une vm java sans la complication des plugins à installer.
Il y a eu de nouvelles annonces de performances vendredi dernier, c'est tout de même assez impressionnant: https://hacks.mozilla.org/2013/12/gap-between-asm-js-and-native-performance-gets-even-narrower-with-float32-optimizations/ .
Et l'argument de Mozilla de ne pas vouloir maintenir 2 langages me semble tout à fait valable.
Pour ma part je code l'interface web de SàT en Python qui est ensuite compilé en Javascript avec Pyjamas: ça me permet d'utiliser un langage que je préfère, et de factoriser une bonne partie du code (un gain de temps très appréciable). asm.js est dans cet esprit et ça me paraît être une bonne direction.
[^] # Re: Git
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal nanim 1.6. Évalué à 2.
Oui j'entends bien, je parlais de séparer dans un autre dépôt. Ça rend le dépôt de code moins lourd (télécharger les binaires à chaque clone, c'est un peu relou et pas cool pour le serveur), et les médias bougent moins souvent a priori (même pour un jeu). Pour SàT le backend est dans sat, les médias sans sat_media: http://repos.goffi.org/
La gestion de version est bien utile pour les binaires aussi, je suis d'accord.
[^] # Re: Git
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal nanim 1.6. Évalué à 3.
Pourquoi avoir lâché fossil, toi qui n'arrêtais pas d'en faire la louange ?
Sinon pourquoi ne pas séparer les données du code ? Ça évide d'avoir un dépôt trop lourd tout en les versionnant. C'est ce qu'on fait pour SàT: d'un côté les médias, et de l'autre le code (mais on a évidemment beaucoup moins de fichiers binaires que pour un jeu). Mercurial s'en sort pas trop mal, m'étonne que ça ne soit pas le cas pour git.
# Quelques réponses en vrac
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 3.
Bon aujourd'hui je suis très pressé, donc je n'ai pas trop le temps de répondre individuellement (y'a beaucoup de commentaires !), aussi je réponds à quelques points rapidement ici:
pourquoi vous imaginez que SàT va être difficile à installer ? Le seul argument (valable) qu'à PHP en face c'est que ça tourne sur des dédiés pré-installés qui souvent ne fournissent que PHP, mais à part ça SàT devrait être très facile à installer, même plus que la plupart des autres vu qu'il intègre son propre serveur web et il n'y aura donc pas de serveur web à installer/configurer. sur une Debian, en gros une installation avec le serveur ça devrait ressembler d'ici l'été prochain à (en root): # apt-get install prosody sat-xmpp-libervia, puis configuration de Prosody (quelques minutes, c'est vraiment facile) et éventuellement quelques autres minutes à configurer 2 bricoles sur SàT (ports à utiliser par exemple). Si vous avez déjà un compte/serveur XMPP, c'est comme installer n'importe quel autre client. J'ai mis Prosody en exemple, mais ça peut être un autre serveur bien sûr.
il n'y a pas besoin d'un serveur particulier qui gère le microblogage ou autre. Nous utilisons notre propre composant Pubsub prévu pour fonctionner avec n'importe quel serveur, il y a juste quelque bricoles qui manquent dans les standards (en particulier la notion de composant privilégié pour pouvoir accéder au roster d'une entité pour ceux qui connaissent XMPP), mais ça n'est qu'une question de temps. Un des buts de XMPP c'est justement de ne pas rester bloquer à un serveur particulier.
Prosody est très bon, je ne comprends pas les critiques à son égard, c'est le serveur qu'on utilise principalement pour les tests, et on n'a jusqu'ici rien eu à lui redire.
XMPP marche entre différents clients pour d'autres choses que juste envoyer du texte, je ne comprends pas pourquoi tu dis ça devnewton ! Le transfert de fichier, les commandes ad-hoc, pubsub, jingle, etc tout ça marche d'un client à un autre. Le microblogage lui est encore en cours d'élaboration, encore une fois un peu de patience.
nous (SàT) n'avons jamais cherché (pour le moment) à avoir des utilisateurs, nous sommes encore en développement et on répète à tous ceux qui veulent essayer « ça n'est pas encore prêt pour la production, uniquement à titre expérimental, bla bla », je me suis même fait reprocher le dernier coup sur DLFP de trop insister là dessus. Ceux qui parlent d'échec ou de stratégie marketing ou que sais-je d'autre n'ont tout simplement pas compris ça. Là on envisage d'avoir une première version grand public d'ici l'été prochain, et ça me semble aujourd'hui réaliste.
Bon pour le reste j'ai d'autre choses à dire, mais je suis très pris en ce moment. Nous avons une 0.4 en préparation qu'on espère sortir avant la fin de l'année, j'en profiterai pour expliquer un peu les (gros) changement récents, et ce qu'on envisage pour l'avenir. RDV probablement un peu avant Noël.
# Expérience
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Lolix. Évalué à 8.
Je n'ai jamais regardé les offres d'emploi ailleurs que sur Lolix, et c'est là que j'ai trouvé mes 2 boulots (2 CV envoyés la première fois, le seul CV envoyé la deuxième). C'était pour moi la garantie d'au minimum pouvoir bosser avec des technos libres. Je pense même qu'il était assez bien vu de la part des recruteurs d'avoir des candidatures venant de Lolix (ça montre des gens intéressés au libre, qui ont souvent une certaine culture technique associée).
Ce serait triste que ça parte.
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 5.
On a choisi XMPP (qui a ses qualités et ses défauts) justement pour pouvoir travailler sur une base commune, qui est déjà suffisamment extensible pour permettre tout ce qu'on veut.
Les autres projets ont choisi de faire leur propre protocole, c'est à mon avis une erreur, mais ils ont leur raisons. Je ne sais pas s'ils ont l'intention de standardiser leurs trucs respectifs (j'imagine qu'ils ont tous l'espoir de devenir suffisamment populaires qu'ils deviennent des standards de fait, mais peut-être que je me trompe).
Enfin bref, de mon point de vue, XMPP a déjà toutes les qualités pour être le « posix » de la communication (mais y'a encore du boulot pour le microblogage).
Le choix de PHP ça peut être stratégique, ou tout simplement parce que c'est le langage que les dév à l'origine d'un projet connaissent le mieux. Pour Movim je sais que c'était stratégique: pouvoir être facilement installable y compris sur un serveur mutualisé (qui fournissent presque toujours un PHP plus ou moins récent). D'autres ont fait d'autres choix (Diaspora c'est Ruby, Newebe* et nous c'est Python), question de goût/point de vue. En tout cas je ne regrette pas une seconde d'être parti sur Python :)
En tout cas, je ne serai pas contre voir un planet dédié à ce genre d'outils, et des réunions de temps en temps…
*P.-S.: honte sur moi j'ai oublié de citer Newebe tout à l'heure !
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 2.
à part reddit (qui n'est pas libre, si ?) je ne connais pas les autres. Est-ce qu'ils sont libres ? Qu'est-ce qu'ils permettent de faire ?
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 6.
On est en réflexion dessus, on a plusieurs possibilités envisagées, mais j'en parlerai un peu plus tard dans une dépêche, vu qu'on a une version sur le feu.
[^] # Re: J'adore ce genre de jeux sur smartphone
Posté par Goffi (site web personnel, Mastodon) . En réponse à la dépêche Ned et les maki 0.1. Évalué à 2.
Je ne me suis pas encore attaqué sérieusement au dev Android aussi peut-être que je dis une connerie, mais l'emulateur du SDK ne suffit pas ?
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 5. Dernière modification le 04 décembre 2013 à 17:56.
On utilise XMPP qui est un standard reconnu, on peut considérer ça comme du « posix ».
On a un backend qui gére toute la partie métier, y compris les extensions, et différents frontaux qui gèrent l'affichage (le tout communicant par un IPC, D-Bus actuellement). On fait en sorte qu'il soit le plus facile/rapide possible de faire un nouveau frontal, et de ne pas être dépendant de technos graphiques (nouvelle techno = nouveau frontal, mais ça consiste surtout à lier les appels D-Bus au comportement graphique adapté).
En gros, ça ressemble à ça:
Maintenant ce qui est demandé ici, c'est de pouvoir étendre l'interface par un utilisateur (je comprends ça comme « mon microblogage s'affiche de telle façon, j'aimerais ajouter un bouton/une image/un schmilblick qui affiche tel code HTML et qui fait tel truc »), soit un truc typiquement graphique.
Or nos frontaux utilisent des environnements graphiques complètement différents:
Libervia est un frontal web, il sort du XHTML
Wix est un frontal WxPython, il sort du WxWidgets
jp est un frontal cli, il sort du texte
Primitivus est un frontal console, il sort de l'Urwid (interface console à la ncurses)
Bellaciao est un frontal Qt et en C++, il sort du Qt
Bref, le bouton à ajouter qui sort un code XHTML ne peut être utilisable que pour Libervia.
Par contre, notre système d'extensions côté backend permet de sortir une interface avec un code XML (une sorte de micro-XUL) qui sera interprété par tous les frontaux ou presque, donc pour les cas simples on peut faire un truc commun.
Bref on essaye de factoriser au maximum, mais il y a des cas où c'est très dépendant de la techno d'affichage, d'où l'intérêt des interfaces multiples, et le probable besoin à terme de faire des extensions liées aux interfaces.
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 2. Dernière modification le 04 décembre 2013 à 17:27.
compatibles entre les frontaux tu veux dire ?
Ben vu que les frontaux peuvent être écrits en n'importe quel language (la plupart sont en Python, on en a un en C++ pour le moment), et avec n'importe quelles bibliothèques, ça me parait compromis.
Les extensions côté backend sont déjà utilisables par tous les frontaux, et elles sont capables d'afficher des interfaces.
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 2.
salt = SàT ? Dans ce cas non en effet, pour le moment les extensions sont uniquement côté backend, mais ça permet déjà de faire beaucoup de choses (à part les RFC de base et quelques XEPs principales, tout est fait sous forme d'extensions), et surtout ça profite à tous les frontaux d'un coup.
À terme si le besoin s'en fait sentir (ça sera probablement le cas au moins pour Libervia, le frontal web), on fera un système d'extensions aussi dans certains frontaux.
[^] # Re: Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 6.
Je ne l'ai pas pris comme ça, et quand bien même je suis ouvert à la critique (enfin si on y met les formes quand même), donc faut pas hésiter, c'est toujours bon d'avoir des retours :)
Bon là faudrait voir directement avec les dévs
Ben oui, faut bien que je justifie mon temps sur DLFP au lieu de bosser sur SàT…
Nous sommes désormais 2 à plein temps sur SàT, et si tout va bien d'ici l'été prochain on devrait avoir une version installable facilement qui offre au minimum microblogage, partage de fichiers, organisation d'événements et chiffrage de bout en bout.
On a une 0.4 qui devrait sortir avant la fin de l'année…
# Ça va venir ça va venir
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mon réseau social centralisé. Évalué à 7. Dernière modification le 04 décembre 2013 à 14:44.
voleur ! ;)
T'as rapporté les bogues à l'équipe de dév ? Timothée bosse beaucoup dessus et avance bien, si tu aides en faisant des rapports de bogues bien comme il faut, m'étonnerait qu'ils restent très longtemps tes bogues.
Bon là c'est pour moi: pourquoi trop geek ? Y'a des fonctionnalités console et tout oui, parce que ça ne fait pas que du microblogage et apparentés, mais l'interface web est prévue pour le grand public, même si elle est encore trop complexe (on y travaille). De toute façon ce n'est pas encore considéré grand public, on prévoit ça d'ici l'été prochain (ça sera la première version nommée).
Et sinon bien sûr que c'est intégrable à un serveur web. Libervia (l'interface web) a son propre serveur web intégré, mais il suffit de faire un reverse proxy sur Apache/Nginx ou autre et c'est réglé.
Oui c'est connu comme projet, et bien que je n'ai jamais essayé je pense pas mal. Mais c'est centralisé, ce n'est pas ce que nous (Movim, SàT, autre) on cherche. Il est nettement plus simple (et donc plus rapide) de faire un réseau centralisé, d'où son avance apparente. Si ça te convient, ben c'est parfait :).
Sinon as tu jeté un œil à Buddycloud, Friendica, Lorea, le fork de Diaspora (dont j'ai oublié le nom), pump.io, Gnu Social/StatusNet/Free social et Tent ?
[^] # Re: ouf le 4 premières minutes ne sont qu'un extrait!
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mythologie du Darknet. Évalué à 4. Dernière modification le 04 décembre 2013 à 12:36.
Wé enfin Freenet ça existe depuis un sacré bout de temps, bien avant Twitter d'ailleurs. C'est un réseau pseudo-anonyme (basé sur un logiciel libre) qui permet d'accéder à des choses comme des sites ou des newsgroups. En plus de l'anonymat il permet la résistance à la censure (tant qu'un contenu est demandé, il est présent dans le réseau, plus il est demandé, plus il est facile à accéder), et la possibilité d'avoir de l'espace disponible sans serveur central (si je mets un fichier d'1 Go et qu'il est demandé, une fois qu'il est inséré sur le réseau je n'ai plus à me soucier de la place nécessaire pour l'héberger). C'est un projet très intéressant qui souffre(ait?) surtout d'une lenteur insupportable.
Darknet ça fait pas mal d'années que j'entends ce mot. Ça reste un terme pour renommer l'existant comme l'informatique aime bien en sortir régulièrement, et c'est probablement ce que Zimmermann a voulu dire dans l'entretien (même si je ne suis pas du tout d'accord avec sa façon de le dire). À ce moment là il serait à placer aux côtés de web 2.0, réseaux sociaux, cloud, etc.
[^] # Re: ouf le 4 premières minutes ne sont qu'un extrait!
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal Mythologie du Darknet. Évalué à 2.
J'ai écouté les 10 première minutes, pour Zimmermann un Darknet c'est « la capacité à 2 ordinateurs de parler le protocole de leur choix, que ça soit chiffré ou anonymisé n'y change rien » ou « internet moins le web ». D'après Wikipédia (francophone et anglophone) c'est bien anonymisé, et c'est la définition que j'ai toujours comprise. Ils ajoutent la notion d'ami à ami (F2F), là du coup c'est moins évident, puisque Freenet première version ne serait pas un Darknet.
À écouter Zimmermann (enfin à moins que j'ai mal compris) XMPP ou FTP c'est du Darknet. À lire Wikipédia, Freenet première version n'est pas un Darknet, TOR ça ne rentre pas dedans non plus. Guiton a l'air plus proche de la définition Wikipédia.
Je pense qu'un Retroshare mettra tout le monde d'accord :)
Du coup va falloir accorder les violons, est-ce qu'il y a une définition « officielle » quelque part ? Ça reste de la pignole, je trouve quand même plus clair de parler de réseau pseudo-anonyme, ou de réseau chiffré, etc.
Enfin je vais écouter la suite, mais pour le moment je ne suis pas convaincu du tout par Zimmermann.
[^] # Re: pv
Posté par Goffi (site web personnel, Mastodon) . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 3.
à lire les commentaires du lien pointé, si !
Mais effectivement, l'idée est sympa et joliment implémentée :)