Goffi a écrit 1524 commentaires

non ?

PS: bonne année toussa toussa

Je m’étonne de ne rien lire sur la fin du monde en ce 21 décembre de l'an 2012

C'est parce que tout le monde est mort, sauf toi (moi je suis un bot qui publie via weboob).

On évitera de s'attarder trop sur les énormités de l'article pointé (« Nous sommes les seuls à proposer une vraie solution de communication modulable. », non mais je rêve !).

Cela rejoint exactement ma réflexion sur le sujet :
http://ploum.net/post/opportunites-manquees-du-libre-2-decentralisation

Oui tout à fait, et d'ailleurs je peux y donner la même réponse: http://ploum.net/post/opportunites-manquees-du-libre-2-decentralisation#c61705 (plus quelques unes plus haut).

Je remets en particulier ce passage, parce que je lis les commentaires du dessus je me rends compte qu'on n'a décidément pas les mêmes combats:

« Productif », « improductif », mais c'est quoi ça ? On ne parle pas de performance, de part de marché, ou de ce genre de conneries, on parle de liberté ! De partage, d'émancipation, d'expression, de lutte. « l'argument moral est tout simplement contre productif »: mais tu te rends compte de l'énormité de ce que tu écris ? Nous ne sommes pas des machines, on a un cerveau et une conscience, c'est bien pour que l'argument moral prenne le pas sur le « productif ».

Je prends peur quand je vous lis parler de « marché », de « créer un nouvel usage » (comprendre un nouveau besoin). Il est désormais clair que nous n'avons pas les mêmes luttes et que nous ne cherchons pas la même chose dans la culture libre.

J'espère qu'il y a encore quelques personnes prêtes à se battre pour des idées, et non pour un marché…

Et je dois représenter à peu près 100% des utilisateurs (mais du coup y'a 100% des utilisateurs qui sont satisfaits, et ça c'est suffisamment rare pour être souligné).

PS: « réseau social » ne veut pas dire grand chose…

Lis le bouquin (ou la page wikipédia déjà). Les mines sont exploitées par l'armée, et le coltan est vendu en sous-main aux entreprises occidentales.

Via le Coltan qui est utilisée dans tout l'électronique, mais en particulier pour la téléphonie mobile. Il y a des gisements importants en République Démocratique du Congo ou au Rwanda, et des mines sont exploités plus ou moins clandestinement. Certains grands constructeurs déclarent ne plus se fournir là et plus en Australie, mais c'est très difficile à contrôler, et il y aurait pas mal d'échanges qui se font en sous main (bon c'est mieux expliqué dans le livre).

Des conclusions parfois un peu faciles, mais c'est globalement très intéressant, et ça appuie là où ça fait mal (je suis dans les hautes technologies, y'a des choses que j'aime dedans, mais pas mal d'autres qui me gênent, comme je l'ai déjà dit en commentaires ou dans des journaux), et on peut y apprendre des choses (l'industrie du téléphone portable qui finance indirectement le génocide Rwandais par exemple).

Pas sûr que ce soit vraiment ce que tu cherches, mais ça reste une lecture intéressante.

Salut,

depuis que Framapad est passé à Etherpad, je ne peux plus m'en servir avec Pentadactyl, je suis obligé de désactiver le plugin. Est-ce que d'autre ont eu le problème et ont une solution ?

Bon en tout cas très bon projet, je m'en sers assez régulièrement (via la version Framasoft donc).

J'ai aussi découvert récemment que des outils natifs permettaient de faire la même chose voir plus, comme Gobby ou Abiword. Si vous en avez d'autres, faites tourner les noms :)

Sur mon site, j'ai customisé muckl pour ça, mais c'est loin d'être parfait, car comme ce n'est pas géré côté serveur, je dois me baser sur l'identifiant des messages. Hors la norme est mal foutu et rien ne garantit que ces identifiants seront uniques, puisqu'ils sont générés par les clients.

Qu'est-ce qu'elle a de mal foutu la norme ? Et tu peux faire tes suggestions sur standards@xmpp.org si quelque chose ne va pas.

L'identifiant du message est facultatif, ça ne me semble pas une très bonne idée de se baser dessus. S'il existe, il est soit unique dans le flux courrant, soit globalement, au choix de celui qui en est à l'origine.

Il y a les threads qui sont prévus pour ce cas (le coup des norloge est juste un façon de présenter), tu peux suivre les recommandation de la XEP-0201: http://xmpp.org/extensions/xep-0201.html . Bon là je n'ai pas trop le temps de me pencher dessus, mais ça ne me parait pas insurmontable à implémenter. Si tu me fais une demande de fonctionnalité (le plus détaillé possible) sur le gestionnaire de bogues de SàT ( http://bugs.goffi.org ) , y'a de bonnes chances que je l'implémente (enfin après la prochaine version, j'ai déjà trop de pain sur la planche là).

J'ai regardé les codes sources de Gajim et Pidgin, mais implémenter la surbrillance au passage de la souris avec les composants GTK qu'ils utilisent à l'air assez difficile.

Tu as essayé de contacter les auteurs ? Ils pourront très certainement te filer un coup de main.

XMPP est "bien" parce qu'il n'y a pas d'alternative.

SIP, IRC, PSYC plus probablement pas mal d'autres que je n'ai pas en tête.

Par contre, il est compliqué

C'est un de ses principes de base d'avoir la complexité côté serveur: pour tout ce qui est fonctions classiques c'est relativement simple. Pour les fonctionnalités avancées du type pubsub c'est plus complexe, mais ça me parait difficile de faire autrement

mauvais pour le chat de groupe (pas de norloge)

oui bon là c'est plus pour troller qu'autre chose, mais pour le chat de groupe je ne connais pas grand chose de meilleur.
Les norloges je ne suis pas contre implémenter ça (je croyais que tu avais déjà fait un plugin pour un client pour ça ?), et je pense qu'Asterix (l'auteur de Gajim) ou d'autres n'auront rien contre un patch.

et la transmission de fichier (souvent lent ou ne marche pas).

Ça c'est tout à fait faux. Si la transmission est lente c'est que tu passes par un proxy ou une copie intégrée (in-band). Les copies classiques sont du socks 5 en P2P, et ça fonctionne au débit permis par les tuyaux.

Le seul vrai inconvénient avec les copies (ce qui peut expliquer leur lenteur), c'est que ça demande d'avoir un port ouvert, une IP bien renseignée, bref un peu de configuration (qui peut se faire automatiquement dans la plupart des cas). Chose qui n'est plus trop nécessaire (a priori, je n'ai pas encore étudié en détails) avec les copies via Jingle, mais ces dernières ne sont pas encore suffisamment courantes.

Premièrement, je vais refermer la parenthèse ouverte avant que certains ressorte le xkcd correspondant ).

(An unmatched plural form creates an unresolved tension that will stay with you all day.

Journal intéressant, je m'y retrouve sur certains points (expérience acquise, difficulté à trouver des contributeurs/faire connaître le projet, communauté d'utilisateurs). Par contre je suis certain que ça sert au moins à quelqu'un: à moi même ;).

J'ai travaillé sur beaucoup de projets dans ma vie, et je me suis rendu compte qu'il est très facile et enthousiasmant de commencer un projet, mais que c'est vraiment tenir sur la durée le plus dur (quand on commence à dépasser les mois de travail). Il faut vraiment être têtu et avoir quelque chose qui nous motive personnellement (et ne pas compter sur les autres pour nous aider: même si ça arrive, c'est rare).

En plus de cela, il est beaucoup plus difficile de lancer un projet aujourd'hui qu'il y a 10 ou 15 ans. Paradoxalement la multiplication des moyens de communication rend plus difficile de rencontrer des gens motivés pour contribuer: il ne suffit plus d'un courriel intéressant sur Usenet. Il y a aussi plus de projets qui se lancent, et donc moins de chance que notre projet particulier intéresse.

Il y a aujourd'hui clairement une partie « marketing » dans le développement d'un projet, ce qui m'insupporte au plus haut point, et est à mon sens une pure perte de temps. Les projets lancés par des personnes plus « visibles électroniquement » ont plus de chances d'attirer l'attention, et je dirais souvent indépendamment de la qualité du projet.

Le choix d'y passer du temps, et les moyens utilisés pour l'« animation de la communauté » sont importants comme tu le soulèves. Maintenant, à moins d'avoir atteint le point où tu as une vraie communauté autour du projet, il est très difficile et risqué de tenir les 2 de front: j'ai vu plusieurs projets qui s'en sortaient bien pour la communication, mais qui ont fini parce péricliter par manque de développement concret.

Je me sers très régulièrement des outils Framasoft: Framadate pour organiser une soirée, le pad pour tout et n'importe quoi (organiser une sortie resto à midi avec les collègues, les trucs qui manquent dans une coloc, traduire/corriger un texte, etc). Bref, un outil prometteur en plus. J'imaginerais bien des interactions XMPP par dessus (déjà pour le chat, puis pour exporter/récupérer les textes, voire pour manipuler directement à terme), peut-être un jour ?

En tout cas bravo :) (ainsi qu'aux dévs et contributeurs d'ether(pad|calc)(*))

(*) D'ailleurs c'est pour « desserrer l'étau » de Google (entre autres), mais il faut reconnaître que c'est eux qui ont libéré les sources.

Tu peux passer n'importe quoi à travers socks via tsocks, même si ce n'est pas prévu pour à la base.

Faudrait déjà commencer par ne pas changer de téléphone tous les 6 mois. Puis accessoirement, ça permettrait de limiter la pollution sociale dans les bars/resto, les transport, et pendant la pause au boulot.

Ça m'a l'air de ressembler pas mal à Newebe, ça apporte quoi de plus (si ce n'est du darwinisme Libre) ?

Bon on est loin de Google et son libéralisme, mais ne pas payer ses impôts parce qu'ils servent à faire la guerre, c'est en plein dans du Thoreau et sa désobéissance civile (et c'était aux É-U pour le coup).

Peut-être qu'ils auraient dû faire un client multi-interfaces ? :)

Une version accentuée par réacc ( http://rali.iro.umontreal.ca/Reacc/Reacc.fr.cgi ). Ce n'est pas parfait, mais déjà plus lisible.

Je prend rarement le temps d'écrire un journal, mais cette fois-ci, j'ai un sujet qui me tiens à coeur, l'avenir de Linux sur le Desktop, voir au delà. La raison, c'est ce blog de Miguel de Icaza : http://tirania.org/blog/archive/2012/Aug-29.html qui est je pense complètement à côté de la plaque. Et une grande partie des commentateurs ne voient que le problème technique sans regarder plus loin et de plus haut. Donc je vais utiliser ce journal pour démarrer une discussion. On verra si plus tard ça vaut le coup de l'internationaliser en la mettant quelque part en Anglais. Désolé, ça va être long.

Apple n'a pas gagné des parts de marché en assurant une API/ABI stable sur MacOS X. C'est juste oublié la partie la plus importante d'Apple. Leur stratégie a été d'attaque au début des années 2000 un domaine moribond, l'électronique grand publique avec l'iPod. Puis un autre domaine pas très innovant, voir complètement sclérose avec l'iPhone. Enfin ils ont créé leur propre niche avec l'iPad. Et tout ça, pour faire vendre par effet de bord des ordinateurs Apple au grand publique. On en est à un point ou pour avoir une expérience optimal, il faut utiliser du matériel Apple. Résultat des developpeurs Linux migrent en masse vers Mac OS X. Il suffit d'aller à n'importe quel événement libre et de compter le nombre d'ordinateur Apple pour voir à quel point le mouvement est massif et terrifiant. L'environnement Linux ne répond déjà même plus au besoin de ses propres developpeurs, alors pour le reste des utilisateurs ! Et le fait que l'un des créateurs de GNOME le dise, est la preuve d'un échec fondamental de mon point de vue…

Google lui avait attaqué dans le domaine du "Cloud" et offre une expérience optimal quand on utilise tous ses services. Résultat la majorité du traffic émail mondial passé par ses serveurs. Un grand nombre de PME/PMI a migré à Google Doc et consort. Il place progressivement Chrome sur le desktop et Android est définitivement un succès de cette stratégie d'intégration. Ils font du Linux, mais pas du GNU/Linux, et un nombre très important de developpeurs préfèrent utiliser les services de Google plutôt que de faire du self hosting. Encore une fois, on arrive plus à se fournir une solution pour nous même.
Microsoft quand à lui a perdu de la vitesse durant la dernière décade, mais clairement pas face à GNU/Linux, uniquement face à Google et Apple qui ont eu une stratégie de contournement sur la principale force de Microsoft, les grandes entreprises. Et Microsoft l'a compris en contre attaquant via son point fort pour faire venir ses tablettes dans les mains des départements informatique.

Chacune de ces sociétés à une stratégie, dont j'ai volontairement forcé le trait, et Linux ? Et bien, je crois que au début des années 2000, l'idée était de copier Microsoft (surtout pour Miguel d'ailleur). Aujourd'hui, on fait pas mieux. Les buzz word qu'y pilote le développement, sont le "Cloud" et les réseaux sociaux. Et je pense vraiment pas qu'une attaque frontale sur Google ou Facebook pourra être une réussite. Je rajouterais aussi ici le cas de Jolla qui veut faire juste un smart phone, mais en utilisant mer/Qt/meego, ne part pas franchement avec une bonne stratégie.
Ma conclusion est que si on continue à suivre le trend a juste créer ce qui existe déjà, alors on va à l'échec et dans quelques années, on n'interressera même plus les developpeurs et GNU/Linux sera juste mort. Il est crucial de tout d'abord fournir un environnement performant pour les developpeurs et ensuite d'avoir une stratégie a long terme.

Mais je pense qu'il ne faut pas chercher à prévenir la fuite des developpeurs actuellement en cour, car le seul moyen de le faire a court terme consiste à suivre Google et Apple. C'est à dire perdre de l'énergie dans une direction qui ne nous permettra jamais de faire de GNU/Linux une plateforme reconnu. Il faut exposer un objectif clair, une vision a long terme et attirer des developpeurs qui sont prêt à faire l'effort d'être sur une plate forme en gestation.
Maintenant quel peut être l'objectif a long terme pour les interfaces graphiques de GNU/Linux ? De mon point de vue, le monde se dirige de plus en plus vert une informatique mobile. Et il sera aussi difficile de se payer une nouvelle tv, un nouveau pc, une nouvelle console, un nouveau smartphone, une nouvelle tablette, une nouvelle voiture, des nouvelles lunettes, un nouveau frigo, un nouveau système domotique à tous les deux ans parce que tout d'abord on est dans une crise économique mondiale colossal et ensuite parce que économiquement ce n'est vraiment pas efficace. La raison "théorique" que les commerciaux veulent nous faire avaler pour faire une mise à jour aussi fréquenté, c'est que l'on a un CPU plus performant et plus de mémoire, et donc si l'on veut les nouveaux services, il faut tout upgrader. Joli plan commercial, mais va falloir être très riche.

Quand on y réfléchit, la seule chose qui change, c'est la taille de l'écran, sa résolution et le périphérique d'entrée qui y est connecté. Et une fois qu'on a atteind une résolution "retina", il n'y a plus de raison de changer d'écran. Et tant que le périphérique d'input ne cassé pas ce n'est pas la peine non plus de le changer. Mais il est vrai que avoir une machine plus puissante tous les 2 ans, c'est quand même nécessaire. Pourquoi est-ce que l'on n'utilise pas le même CPU/GPU pour toutes les machines ? Aujourd'hui, c'est une limitation plutôt de facilité. Si il fallait débrancher puis rebrancher une "unité centrale" à chaque fois que je passe de mon PC à une tablette, ça serait vraiment pas drôle.

Mais les technologies sans fil font de très gros progrès. Pour l'affichage on a Wireless Display, le Wifi pour le réseau, le bluetooth pour les périphériques d'input et diverse techno de rechargement sans fil. On peut donc aujourd'hui réaliser une tel "unité centrale". En fait, cette "unité centrale" à besoin d'un écran pour pouvoir poser quelques questions à l'utilisateur lors de l'appairage a un écran/périphérique d'input… Ça ressemble vaguement à un truc existant… Cette idée pose des contraintes :

• il faut penser les applications pour qu'elle consomme le moins de ressource, donc les optimiser et avoir une architecture logiciel là plus optimal, car on ne sera pas toujours dans le champs d'un chargeur sans fil.

• il faut penser les applications pour qu'elle soit utilisable sur des écrans et avec des périphériques d'input très différente.

• il faut protéger le système en cas de vol, car toutes les données seront accessible depuis cette "unité centrale".

• il faut un système de synchronisation/backup sécurise et efficace.
  Si on veut permettre à des entreprises externe de contribuer aux systèmes :

• il faut augmenter la sécurité de Linux (pour commencer se débarrasser de X et passer à Wayland).

• il faut garantir la stabilité des API/ABI pour plusieurs années (au minimum 5 ans).

• il faut mettre en place un mécanisme de "store" permettant facilement à une société de déployer leur application sur de nombreuse distribution (je pense que pour l'instant, Valve avec Steam est là mieux placé pour cette tâche).
  Si on veut être innovant :

• il faut être capable de permettre à toutes les applications de lié des informations de manière pertinente et leur permettre d'extraire des informations enrichit par d'autres applications (dans l'idéal sans compromettre la sécurité du système).

• il faut penser le système pour être extensible et ouvert (contrairement à un certain nombre de standard freedesktop).
  Cela représente déjà beaucoup de travail et je pense qu'il y en a pour quelques années avant d'atteindre un tel objectif. Pour ce qui est du matériel, ça ressemble franchement à un smart phone. D'ailleur un Galaxy S3 est plus puissant qu'un netbook d'il y a un ou deux ans, et il a déjà un port hdmi et usb. C'est déjà juste une question logiciel aujourd'hui, même si il faudra sûrement attendre quelques années, probablement plus de 3 ou 5 ans, avant d'avoir des téléphones vraiment capable de tout faire. Mais c'est en s'y prenant aujourd'hui qu'on peut avoir une chance !

N'empêche que ça a l'air pas mal du tout ton système, t'as déjà essayé de le proposer en XEP ? Ça aiderait fort à son utilisation, surtout tu as déjà fait une implémentation. En tout cas ça me plairait bien d'utiliser ça.

J'avais vu ton journal, mais je n'ai pas eu le temps de regarder en détails comment tu as fait. La fonctionnalité en elle-même est intéressante ( dans l'idéal il faudrait pouvoir afficher les fils de discussions de plusieurs manières, et les norloges seraient une « vue »). En tout cas ça fait un moment que je pense le faire dans SàT. Sinon tu as regardé du côté de oneteam ? Ils ont un support des fils de discussions (cf Nycö).

Oui, on peut reprendre un transfert à un octet précis. Ça se gère côté client.

Pour le partage de fichier il y a un héritage historique. Tu as basiquement 3 façon de faire:

• le partage via des messages ( XEP-0047 ), qui passe pratiquement partout (sauf si c'est explicitement filtré comme c'est le cas je crois sur FB). C'est lent, dépendant du serveur, consommateur en resources. C'est vraiment une solution de secours quand rien d'autre ne marche, pour des petits fichiers

• la partage traditionnel ( XEP-0096 ): le plus implémenté. Selon la configuration, tu as une connection P2P (directe donc), et là c'est uniquement limité par ta connection. En cas de problème (NAT, Firewall ou autre joyeuseté), ça tente le coup via un proxy, ce qui limite la vitesse de connection.

• ce va progressivement devenir la norme ( XEP-0234 ), via Jingle: là c'est beaucoup plus moderne et robuste, ça traverse plus facilement les réseaux à problèmes. Au finale, comme pour le précédent, ça cherche à établir une connexion directe.

XMPP sert à la négociation, et hormis dans le premier cas, le transfert à proprement parler est fait de manière externe, souvent via SOCKS5. Il n'y a aucune raison que ça soit lent, sauf problème de configuration (ça ira mieux quand on sera tous passé à Jingle, c'est prévu pour SàT mais pas pour la version qui vient).

Oui désolé, je n'ai aucune mémoire des noms/pseudos, j'ai confondu avec quelqu'un de BeWelcome :p. C'est bien à toi que je faisais référence :)