mahikeulbody a écrit 1656 commentaires

> Waze s'était le top avant le rachat par google (qui assure un espionnage temps réel)

A mon avis, sur un téléphone Android associé à un compte Gmail (ce qui est quand même l'usage le plus courant), Google n'a pas besoin qu'on utilise Maps (ou Waze) pour logguer nos déplacements. Donc l'argument "espionnage" en défaveur de Maps (ou Waze) ne me semble pas pertinent…

> la majeure partie des informations se situent sur le compte XMPP.

Les quelques lectures que j'ai pu faire sur XMPP m'indiquent qu'un serveur XMPP stocke essentiellement les contacts et les messages en attente de pouvoir être délivrés (si le client - ici Movim - est offline). J'en déduis que l'historique des messages est seulement stocké dans le pod Movim. Or, ta réponse ci-dessus laisse penser que même les messages/billets sont stockés sur le serveur XMPP puisqu'en se connectant sur un autre pod celui-ci va récupérer ces infos.

Que stocke un serveur XMPP ?

> Donc en se connectant avec le même compte depuis un autre pod toutes ces informations seront automatiquement synchronisées.

Super ! Même si ma question portait surtout sur la possibilité de changer de pod je suis curieux de savoir de quel type de synchro il s'agit : bi-directionnelle (et si oui, "nettoyer" un pod ne risque pas de "nettoyer" l'autre ?)

> Le seul truc qui ne peut pas être déplacé sont les images hébergés sur l'ancien pod.

C'est une limitation intrinsèque à XMPP, à la techno utilisée coté serveur ou bien est-ce une limitation qui pourrait être levée un jour si nécessaire ? Et quand on parle d'image hébergée, cela inclut également les images insérées dans un post (auquel cas, une synchronisation sur un autre pod pourrait "dégrader" certains posts) ?

Peut-on facilement transférer ses données en cas de changement de POD ?

J'attends le lancement de la campagne sur kickstarter pour contribuer (au fait, vous avez prévu un post ici pour nous en informer quand elle sera ouverte ?).

C'est complètement subjectif mais je trouve que le nom (Salut à Toi) est très sympa mais pas "vendeur". A cet égard, je trouve que Movim "passe" mieux.

A propos de Movim, peut-on considérer que les deux projets ont la même cible fonctionnelle ou bien y a t-il des applications de l'un qu'on a peu de chances de voir sur l'autre (et vice versa) ?

Pour les fonctionnalités de base que les deux ont (ou auront) - chat, micro-blogging, partage, etc… - quels sont les critères qui peuvent conduire à préférer l'un plutôt que l'autre ? Par exemple, les deux permettent-ils de changer de serveur sans perdre son historique ? Puis-je passer de l'un à l'autre ?

En tous cas bravo à tous les deux (et à ceux qui vous accompagnent dans ces deux projets).

Même si j'ai quelques interrogations sur la viabilité au quotidien de la solution, c'est une réponse intéressante et plus constructive que celle des poncifs d'AgentSteel…

Ceci dit, c'est un journal qui parle de YunoHost, pas de la pertinence de l'auto-hébergement. Je n'aurais pas dû faire ce commentaire hors sujet, je m'en excuse auprès de M5oul.

Si, ça existe, mais le faire tous les jours dans les conditions que tu décris (le mettre dans un lieu sûr autre que ton domicile), c'est en général impossible. Sinon, on peut aussi ne le faire que tous les mois, mais c'est en général impensable.

A part ça, une (vraie) question : l'expression "auto-hébergement" est-elle nécessairement associée à un hébergement à domicile ou bien définit-elle, plus largement, un hébergement géré par soi-même (mais pas nécessairement chez soi) ?

PS. Je préfère ignorer ta dernière remarque, certes irréfutable, mais que j'ai du mal à insérer de façon utile dans mon questionnement sur l'auto-hébergement.

Dans le cloud, oui bien sûr. Du coup, c'est quoi l'intérêt de s'auto-héberger (chez soi, j'entends) ?

Par contre il y a toujours l'excuse que le domicile peut brûler ou être cambriolé…

Je me corrige : éliminer les doublons tout en voulant garder l'info donné par les étiquettes peut faire sens si dans gmail aucun mail n'a été affecté de plus d'une étiquette (automatiquement ou via une action utilisateur). Ils n'apparaissent donc que dans le répertoire local 'Tous les messages' et dans, au plus, un autre répertoire du nom de l'étiquette. On peut alors vouloir supprimer les occurrences présentes dans le répertoire 'Tous les messages' si le même message apparaît aussi dans un autre répertoire, et un seul autre. A la fin de l'opération, le répertoire 'Tous les messages' gagnera à être renommé, 'Autres messages' par exemple.

Dans Gmail, il n'y a que trois répertoires :
- Tous les messages
- Spam
- Poubelle

Les autres "répertoires" sont fictifs, en réalité ce sont les résultats de requêtes implicites : select les mails de 'Tous les messages' ayant telle étiquette (Boite de réception, Messages envoyés, Chat, ou bien une étiquette personnalisée créée par l'utilisateur). Un mail n'est jamais dupliqué : si on le supprime d'une des vues où il apparaît, il est supprimé de 'Tous les messages' et donc de toutes les autres vues où il apparaît éventuellement.

Si on accède à son compte via un client IMAP, on a le même fonctionnement.

En revanche, si on archive localement les messages de 'Tous les messages' ainsi que ceux "apparaissant" dans les vues, on va peut effectivement avoir des doublons. Si on n'est pas intéressé par les étiquettes, le plus simple est de ne garder que le répertoire 'Tous les messages' (et, s'il y a lieu, les répertoires Spam et Poubelle). Si on veut garder les étiquettes, c'est qu'on veut garder les doublons => les éliminer ne fait pas de sens.

Or, si le code n'est pas libre, le format des données est potentiellement inconnu, non documenté, non réutilisable>

Je ne comprends pas : il y a des tas de logiciels/services cloud non libres qui utilisent des formats de données connus, documentés, réutilisables (et même, parfois, libres), non ?

Je croyais qu'on était samedi ? Mais non, je dois forcément me tromper, ça ne peut être que vendredi.

Je "marronne" (?) parce que n'étant pas sûr de ma compréhension d'une phrase j'ai tout d'abord demandé ce qu'il en était pour être sûr. C'est seulement suite à la réponse très condescendante qui m'a été faite que je me suis moi-même permis une réponse ironique qui a débouché sur ce "débat" hors sujet et qui au fond ne m'intéresse pas plus que ça.

Imaginons un monde où il faudrait le code ET la signature pour engager sa responsabilité dans une transaction. Comment le décrire de façon fiable si le ET peut aussi bien signifier un OU. Comprendre la réponse de façon contextuelle ne devrait pas induire qu'on connaît déjà la réponse à la question. Je n'imagine même pas les cris d'orfraie si un texte administratif utilisait ce genre de formulation… Bref, au delà du débat sémantique (hors-sujet) j'ai trouvé la réponse assez condescendante.

Tu veux dire que le OU est inutile dans la langue française puisqu'on peut utiliser le ET avec la même sémantique ?

j'avais regardé la législation et seuls ta signature et ton code à 4 chiffres engageaient vraiment ta responsabilité.

La signature seule n'engage pas ? Qu'en est-il si j'utilise ma carte française aux USA où le code à 4 chiffres est très peu utilisé ? Et c'est à la banque de prouver que c'est une signature contrefaite ?

Ici et là, quand on parle de SSII, on a l'air de parler en fait de boites d'intérim spécialisées en informatique, où l'informaticien est envoyé en mission chez un client chez qui il est un peu l'esclave et où il est complètement oublié par sa boite. Il me semble pourtant qu'il existe aussi des SSII qui réalisent des projets clé en main en interne, projets pouvant durer plusieurs années parfois, souvent de grands projets qu'une direction informatique ne peut se permettre de réaliser elle-même. J'ai fait toute ma carrière (37 ans) dans l'une d'elle et je n'ai jamais fait de missions chez un client (enfin si, deux mois, et je n'ai pas trop aimé). Je ne dis pas que mon ex-boite n'envoie pas aussi des gens en mission, mais c'est loin d'être la plus grande part. Alors, c'est si rare (et j'ai eu beaucoup de chance) ?

Entre autres pistes : la création monétaire. Je ne suis pas un spécialiste mais l'idée du revenu de base semble une vraie théorie élaborée par des gens sérieux et non un juste un doux rêve d'illuminés gauchistes. Reste que comme ça n'a jamais été expérimenté autrement qu'à l'échelle locale, il est difficile de savoir ce que ça donnerait en pratique. Pour une approche simplifiée on peut lire l'article de Wikipedia sur ce sujet passionnant.

Ce que je voulais souligner c'est que ta phrase "En revanche rien n'oblige B à fournir les sources aux auteurs originaux" pouvait être mal comprise si prise à la lettre. En réalité, la GPL oblige bel et bien B à fournir les sources à A si A les demande puisque B a distribué ce logiciel à un tiers (C) et ne s'est donc pas limité à un usage interne.

Si j'ai bien compris*, tout comme la GPL, la RPL n'oblige pas à diffuser spontanément les modifications. Ce qui la différencie de la GPL, c'est que les modifications doivent être disponibles même si le code modifié est à usage interne (i.e. pas redistribué à un tiers).

Un employeur a le droit d'interdire à ses employés de diffuser spontanément les modifications (la licence n'oblige à diffuser spontanément), il peut aussi sans doute dans la plupart des cas leur interdire de parler du projet à l'extérieur, tout ça sans être en situation illégale vis à vis de la RPL. Dans ces conditions, la différence avec la GPL est assez théorique…

*à la lecture de wikipedia, je précise que j'ai pas lu la licence elle-même.

La seule différence que je vois avec la GPL est que la RPL oblige aussi à redistribuer même si les modifications sont à usage interne (regardless of whether those changes deploy internally or to third parties). Je ne vois pas comment on peut contrôler ça…

En revanche rien n'oblige B à fournir les sources aux auteurs originaux.

Il serait plus exact de dire que rien n'oblige B à fournir spontanément les sources aux auteurs originaux.

an answer from Christopher Halse Rogers

Présenter ce commentaire comme un résumé, c'est intellectuellement malhonnête…

J'invite ceux qui comprennent l'anglais à lire le post et les commentaires pour se faire leur propre opinion.