En pratique je ne connais pas beaucoup de logiciels qui maintiennent en même temps plusieurs version en parallèle. Il faut des ressources pour se permettre de développer à la fois les nouvelles fonctionnalités de la version 2 et maintenir la version 1.
Ce qui est important effectivement c'est l'adaptation de la graine au lieu. Par sélection génétique sur des décénies, la graine est parfaitement adaptée a son jardin.
Vouloir comparer est normal, ils arrivent après, XMPP existe, et les gens ont besoin de comprendre pourquoi ils doivent investir dans une nouvelle techno alors qu'il y avait XMPP qui ne demandait qu'a évoluer.
C'est un peu comme Mir vs Wayland (d'ailleurs la FAQ de Mir sur Wayland était bien pourrie).
Pour moi, Matrix voulait refaire de la messagerie, avec un style très orienté IRC. Ils voulaient aller vite. XMPP leur donnait l'impression de stagner donc ils ont voulu s'en abstraire pour aller plus vite et par raisons marketing De toute façon, ça n'avait plus la cote… et ils ont fait un protocole fait au plus rapide avec une couche HTTP+JSON parce qu'il y a plein de libs qui marchent bien pour ça, c'est tout.
Il doit également y avoir des raisons techniques. Je pense que l'implémentation des utilisateurs et des salons de discussion est différente de XMPP et c'est souhaité. Si ils avaient dû reprendre XMPP, ils n'auraient peut être pas pu reprendre les mêmes groupchat et auraient fait leur truc séparé sans doute.
Disclaimer : on était ensemble sur framatalk. Somme toute, c'était un des meilleurs outils qu'on ait testé. Ça nous arrivait d'avoir des problèmes d'echo avec l'autre coté de l'atlantique, mais sinon, ça marchait bien. Surtout pour quelque chose qui tourne dans un navigateur uniquement. Donc n'hésitez pas a tester également.
D'un point de vue purement théorique sur la manière dont fonctionne terraform, il a un gros avantage par rapport a Ansible, Chef ou Puppet : il stocke son état courant.
En pratique ça veut dire que lorsqu'on enlève une ressource du fichier terraform, au prochain lancement, il va se souvenir que la ressource existait, quelle n'existe plus, et il tentera de la supprimer. Dans les faits, ça lui permet d'être toujours au plus proche de son état.
Des outils de gestion de conf classique, en cas de suppression d'une ressource dans les sources, ne vont pas la supprimer. Elle restera là sur les serveurs. Ce qui je trouve peut poser problème. Imagine que ce soit un serveur avec une faille de sécurité… En pratique, la solution est d'indiquer la ressource mais avec une booléen pour dire qu'elle doit être absente. Pas très propre je trouve.
En constatant cela, j'ai immédiatement pensé a comment faire pour utiliser terraform a la place de puppet, chef ou ansible. En pratique, c'est pas faisable … dans terraform on ne gère pas des fichiers, des services ou d'autres objets existant sur la machine où on exécute terraform. Ce que fait terraform c'est gérer des ressources distantes par API Web.
Mais en pratique, terraform permet l'écriture de plugins. En théorie rien n'empêche donc d'écrire un plugin qui au lieu de discuter avec une API Web, discutera avec une API d'appel systèmes pour provisionner une machine réelle et pas dans le cloud.
Après, en pratique, je n'ai pas tenté cette voie parce que terraform n'est vraiment pas fait pour ça, et rien ne dit que ça marchera pour tout faire. Et il n'y aura aucune volonté de merger du code sur ces fonctionnalités upstream. Ce serait un gros hack en quelque sorte. mais si vous avez du temps a faire, ça peut être un truc cool :)
Sachant qu'il existe un outil : mgmt (déjà discuté plus haut), tout neuf, écrit par un gars de Red Hat qui pourrait remplir ce rôle parfaitement.
Local user-to-root privilege escalation exploit within the Hardware Abstraction Layer (HAL) daemon. Exploit is available on Linux and PC-BSD platforms with the hald process running.
Les macs de 2007 (Core2Duo MacBook2,1) ont un EFI (c'était pas encore UEFI a cette époque) 32 bits alors que ton OS est souvent 64bits. Du coup, si tu présentes une clé avec une code de boot 64bits, ça ne marche pas.
Solution: faire tout en 32bits, ou avoir une distro qui te file un EFI 32bits et un kernel 64bits. Et ça, pas grand monde le fait.
J'ai comme l'impression que chromium cache la page complètement sur disque. Avec un ordinateur pas très puissant, et pas beaucoup de RAM, chromium est nettement plus réactif que Firefox. Il faut dire que j'ai une sale habitude : avoir minimum 40 onglets ouverts, si ce n'est 120.
Sans doute que Firefox devra se mettre a faire ça, si ils décident d'activer un process par onglet (au lieu d'un process pour tous les onglets comme maintenant)
J'ai du mal a voir comment une extension binaire est capable de protéger du contenu. A mon sens, c'est complètement vulnérable a une attaque de type replay attack. Et je ne suis pas seule a le penser, il semble : EME undermines its stated purpose
It's stated in the abstract that the EME purpose it's for "providing APIs to control playback of protected content" but a standard (open) API undermines all content protection schemes using it thereby defeating its reason for existing.
There are a couple ways this can manifest:
If the protected content, CDM, license requests/responses are all written to disk by the browser then they can be packaged into a single file for later playback.
The CDM is architecture and OS agnostic, so it cannot make direct rendering calls. As a result, any possible output from the CDM can be recorded to disk as an unprotected media format.
En gros, il dit qu'il y a deux manières pour récupérer le contenu quand même :
en interceptant les accès au serveur de DRM, et en contrôlant l'état du module DRM, il est possible de rejouer les requêtes réseau afin de redéchiffrer le contenu.
en interceptant les frames déchiffrées, on peut reconstituer le flux vidéo non chiffré
En gros, cela revient, l'un comme l'autre a exécuter le module DRM dans une machine virtuelle, ou toutes les entrées sont connues, et si on peut faire ça, plus rien ne tient.
Dans le cas contraire, le module DRM est très lié au matériel et ne peut s'exécuter dans une machine virtuelle, on va rester dans le problème classique ou ces modules vont être sous une forte pression de reverse engineering pour réussir a accéder a une interopérabilité.
Ça n'a rien a voir, l'injection SQL permet a un attaquant d'attaquer une application via sa base de donnée.
Ici le cas de figure est un abonné free qui attaque directement la base de donnée pour avoir un accès privilégié sur les serveurs de free et donc faire plein de choses qu'il n'aurait pas pu faire sinon.
Autant sur le reste des critiques, je ne les partage pas, mais effectivement, le RaspberryPI me semble fort limité pour quelque chose comme Cozy. On a pas besoin de port HDMI !
Par contre, on a effectivement besoin d'IO descentes, de gigabit ethernet et de SATA (voire multiple SATA pour faire du RAID).
D'une manière générale, je regrette que tout se fasse a base de Raspberry. Il manque une alternative orientées stockage de données (pour Cozy par exemple) et une autre alternative orientée réseau pour faire son routeur maison (gigabit ethernet, switch ethernet intégré, pas besoin de SATA ni HDMI).
Vous connaissez des alternatives spécialisées dans ce genre ressemblant dans l'esprit au Raspberry ?
C'est vrai que par choix, je choisirais plutôt de l'écrire en Go, de par sa simplicité de déploiement (compilé en statique) et de par la facilité de la cross compilation. Mais le C n'est pas si mal non plus.
L'esprit de la LGPL veut que tu puisse modifier le code LGPL, et exécuter le même soft avec ton nouveau code. Pour cela, tu as besoin d'un link dynamique. Donc de l'extérieur, tu as bel et bien besoin d'avoir une lib séparée.
En pratique, les deux sont aussi dangereux si tu ne fait pas confiance au mec qui écrit le script derrière (shell ou post install). Par contre, le paquet de la distrib a l'avantage de ne pas pourrir complètement ta distribution. Tu peux le désinstaller. Rien que ça, c'est un énorme avantage.
La politique au sens large n'est pas spécifique a un pays. La politique c'est aussi discuter du fonctionnement de la société au sens large. C'est pas juste un bulletin dans une urne. C'est très réducteur comme approche.
Et le fonctionnement de la société est un sujet qui est loin d'être spécifique a un pays en particulier.
Sans compter que le logiciel libre au sens de la FSF est un sujet hautement politique en lui même.
A savoir que je pense qu'un journal peut très bien être dans la seconde page mais être très pertinent, alors qu'il peut y avoir des journaux de première page moins pertinents. C'est a mon avis une problématique orthogonale.
La première page contiendrait les journaux dans le thème, la seconde page, les journaux bookmark ou HS. La première page a une prévisualisation extensive, alors que la seconde page ne prévisualise que ~5 lignes dans la colonne de gauche (25 mots max).
C'est effectivement une remarque très juste. Si je ne me trompe pas, on a actuellement plusieurs implémentations des interfaces wayland : weston, enlightnment, gnome-shell, kwin. Rien ne garantit qu'ils fonctionnent de manière identique ou qu'ils implémentent exactement les mêmes protocoles.
Le problème avec GNU/Linux, c'est que la distribution linux a typiquement un peu d'autres trucs que juste les soft GNU. Dans le désordre, on a l'init (sysv, systemd), udev, Xorg (ça, c'est vraiment pas un projet GNU avec une licence pareille)…
Du coup, je trouverait ça logique de l'appeler GNU/Xorg/Linux (l'init étant tellement proche du noyau linux qu'il peut y être assimilé).
comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable.
Pour ma part, je vois un inconvénient principal : on devient dépendant du serveur qui maintient notre JID. Que ce soit le nôtre ou pas. Typiquement, j'ai un compte sur jabber.fr, que je n'utilise plus, parce que les certificats SSL n'ont pas été renouvelés. La migration vers un autre serveur est trop coûteuse pour que j'en voit l'intérêt.
Comparé a IRC, peu importe le serveur sur lequel je me connecte, ça marche toujours aussi bien. Alors certes, IRC n'offre pas le même service, mais finalement ça me convient mieux.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
Tout a fait, et ça peut aussi poser des problèmes sur les nœuds a la périphérie du réseau comme les appareils mobiles qui n'ont pas forcément la bande passante ou la batterie nécessaire.
Par contre, malgré cela, il faut tout de même tendre vers du distribué dans le sens ou chaque nœud fait partie intégrante du réseau. Dans le cas de synthing, on a le choix de ne pas avoir de serveur (et donc une dispo des données moins importante) ou monter (ou louer) un serveur pour avoir une dispo plus importante. Le choix est possible et est fait en toute connaissance de cause.
[^] # Re: Un lecteur vidéos ?
Posté par Mildred (site web personnel) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 2.
J'utilise, mais ce qui me manque le plus c'est de pouvoir ouvrir deux vidéos en même temps, pas juste la playlist.
[^] # Re: Flatpak
Posté par Mildred (site web personnel) . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 6.
En pratique je ne connais pas beaucoup de logiciels qui maintiennent en même temps plusieurs version en parallèle. Il faut des ressources pour se permettre de développer à la fois les nouvelles fonctionnalités de la version 2 et maintenir la version 1.
[^] # Re: Mon expérience : la papi Louis
Posté par Mildred (site web personnel) . En réponse à la dépêche Open Source Seeds : les graines de tomates libres. Évalué à 4.
Ce qui est important effectivement c'est l'adaptation de la graine au lieu. Par sélection génétique sur des décénies, la graine est parfaitement adaptée a son jardin.
[^] # Re: Point de vue d'un développeur XMPP
Posté par Mildred (site web personnel) . En réponse à la dépêche Matrix pour décentraliser Skype, Whatsapp, Signal, Slack et Discord. Évalué à 7.
Vouloir comparer est normal, ils arrivent après, XMPP existe, et les gens ont besoin de comprendre pourquoi ils doivent investir dans une nouvelle techno alors qu'il y avait XMPP qui ne demandait qu'a évoluer.
C'est un peu comme Mir vs Wayland (d'ailleurs la FAQ de Mir sur Wayland était bien pourrie).
Pour moi, Matrix voulait refaire de la messagerie, avec un style très orienté IRC. Ils voulaient aller vite. XMPP leur donnait l'impression de stagner donc ils ont voulu s'en abstraire pour aller plus vite et par raisons marketing De toute façon, ça n'avait plus la cote… et ils ont fait un protocole fait au plus rapide avec une couche HTTP+JSON parce qu'il y a plein de libs qui marchent bien pour ça, c'est tout.
Il doit également y avoir des raisons techniques. Je pense que l'implémentation des utilisateurs et des salons de discussion est différente de XMPP et c'est souhaité. Si ils avaient dû reprendre XMPP, ils n'auraient peut être pas pu reprendre les mêmes groupchat et auraient fait leur truc séparé sans doute.
[^] # Re: s/Skype/web/
Posté par Mildred (site web personnel) . En réponse au journal Au revoir Skype, bonjour Matrix et Riot. Évalué à 2.
Disclaimer : on était ensemble sur framatalk. Somme toute, c'était un des meilleurs outils qu'on ait testé. Ça nous arrivait d'avoir des problèmes d'echo avec l'autre coté de l'atlantique, mais sinon, ça marchait bien. Surtout pour quelque chose qui tourne dans un navigateur uniquement. Donc n'hésitez pas a tester également.
# Plugins
Posté par Mildred (site web personnel) . En réponse à la dépêche Sortie de Terraform 0.9. Évalué à 3.
D'un point de vue purement théorique sur la manière dont fonctionne terraform, il a un gros avantage par rapport a Ansible, Chef ou Puppet : il stocke son état courant.
En pratique ça veut dire que lorsqu'on enlève une ressource du fichier terraform, au prochain lancement, il va se souvenir que la ressource existait, quelle n'existe plus, et il tentera de la supprimer. Dans les faits, ça lui permet d'être toujours au plus proche de son état.
Des outils de gestion de conf classique, en cas de suppression d'une ressource dans les sources, ne vont pas la supprimer. Elle restera là sur les serveurs. Ce qui je trouve peut poser problème. Imagine que ce soit un serveur avec une faille de sécurité… En pratique, la solution est d'indiquer la ressource mais avec une booléen pour dire qu'elle doit être absente. Pas très propre je trouve.
En constatant cela, j'ai immédiatement pensé a comment faire pour utiliser terraform a la place de puppet, chef ou ansible. En pratique, c'est pas faisable … dans terraform on ne gère pas des fichiers, des services ou d'autres objets existant sur la machine où on exécute terraform. Ce que fait terraform c'est gérer des ressources distantes par API Web.
Mais en pratique, terraform permet l'écriture de plugins. En théorie rien n'empêche donc d'écrire un plugin qui au lieu de discuter avec une API Web, discutera avec une API d'appel systèmes pour provisionner une machine réelle et pas dans le cloud.
Après, en pratique, je n'ai pas tenté cette voie parce que terraform n'est vraiment pas fait pour ça, et rien ne dit que ça marchera pour tout faire. Et il n'y aura aucune volonté de merger du code sur ces fonctionnalités upstream. Ce serait un gros hack en quelque sorte. mais si vous avez du temps a faire, ça peut être un truc cool :)
Sachant qu'il existe un outil : mgmt (déjà discuté plus haut), tout neuf, écrit par un gars de Red Hat qui pourrait remplir ce rôle parfaitement.
# HAL est troué
Posté par Mildred (site web personnel) . En réponse au journal La CIA offre sa première fournée de logiciels non libres gratuits. Évalué à 3.
https://wikileaks.org/ciav7p1/cms/page_9535850.html
[^] # Re: UEFI
Posté par Mildred (site web personnel) . En réponse au journal Libérer un Mac/Intel. Évalué à 6.
Les macs de 2007 (Core2Duo MacBook2,1) ont un EFI (c'était pas encore UEFI a cette époque) 32 bits alors que ton OS est souvent 64bits. Du coup, si tu présentes une clé avec une code de boot 64bits, ça ne marche pas.
Solution: faire tout en 32bits, ou avoir une distro qui te file un EFI 32bits et un kernel 64bits. Et ça, pas grand monde le fait.
[^] # Re: e10s
Posté par Mildred (site web personnel) . En réponse à la dépêche Firefox 49 en chansons. Évalué à 2.
J'ai comme l'impression que chromium cache la page complètement sur disque. Avec un ordinateur pas très puissant, et pas beaucoup de RAM, chromium est nettement plus réactif que Firefox. Il faut dire que j'ai une sale habitude : avoir minimum 40 onglets ouverts, si ce n'est 120.
Sans doute que Firefox devra se mettre a faire ça, si ils décident d'activer un process par onglet (au lieu d'un process pour tous les onglets comme maintenant)
# Encrypted Media Extensions : est-ce que ça va vraiment marcher ?
Posté par Mildred (site web personnel) . En réponse à la dépêche Firefox 49 en chansons. Évalué à 6.
J'ai du mal a voir comment une extension binaire est capable de protéger du contenu. A mon sens, c'est complètement vulnérable a une attaque de type replay attack. Et je ne suis pas seule a le penser, il semble : EME undermines its stated purpose
En gros, il dit qu'il y a deux manières pour récupérer le contenu quand même :
En gros, cela revient, l'un comme l'autre a exécuter le module DRM dans une machine virtuelle, ou toutes les entrées sont connues, et si on peut faire ça, plus rien ne tient.
Dans le cas contraire, le module DRM est très lié au matériel et ne peut s'exécuter dans une machine virtuelle, on va rester dans le problème classique ou ces modules vont être sous une forte pression de reverse engineering pour réussir a accéder a une interopérabilité.
[^] # Re: faudrait donner quelques explications.
Posté par Mildred (site web personnel) . En réponse au journal Fin du monde en vue ?. Évalué à 1.
Ça n'a rien a voir, l'injection SQL permet a un attaquant d'attaquer une application via sa base de donnée.
Ici le cas de figure est un abonné free qui attaque directement la base de donnée pour avoir un accès privilégié sur les serveurs de free et donc faire plein de choses qu'il n'aurait pas pu faire sinon.
[^] # Re: Stop avec le RapberryPI
Posté par Mildred (site web personnel) . En réponse à la dépêche Donnez votre avis sur la nouvelle architecture de Cozy. Évalué à 2.
Autant sur le reste des critiques, je ne les partage pas, mais effectivement, le RaspberryPI me semble fort limité pour quelque chose comme Cozy. On a pas besoin de port HDMI !
Par contre, on a effectivement besoin d'IO descentes, de gigabit ethernet et de SATA (voire multiple SATA pour faire du RAID).
D'une manière générale, je regrette que tout se fasse a base de Raspberry. Il manque une alternative orientées stockage de données (pour Cozy par exemple) et une autre alternative orientée réseau pour faire son routeur maison (gigabit ethernet, switch ethernet intégré, pas besoin de SATA ni HDMI).
Vous connaissez des alternatives spécialisées dans ce genre ressemblant dans l'esprit au Raspberry ?
[^] # Re: Pourquoi en C ?
Posté par Mildred (site web personnel) . En réponse au journal Ulfius: framework pour faire des API Web en C. Évalué à 2.
C'est vrai que par choix, je choisirais plutôt de l'écrire en Go, de par sa simplicité de déploiement (compilé en statique) et de par la facilité de la cross compilation. Mais le C n'est pas si mal non plus.
[^] # Re: Snappy vs compilation statique
Posté par Mildred (site web personnel) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 2.
L'esprit de la LGPL veut que tu puisse modifier le code LGPL, et exécuter le même soft avec ton nouveau code. Pour cela, tu as besoin d'un link dynamique. Donc de l'extérieur, tu as bel et bien besoin d'avoir une lib séparée.
[^] # Re: Linux for desktop !!!
Posté par Mildred (site web personnel) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 2.
Ou alors la distribution peut refuser un paquet qui fait trop de link statique comme Chromium avec Fedora
[^] # Re: Linux for desktop !!!
Posté par Mildred (site web personnel) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 1.
En pratique, les deux sont aussi dangereux si tu ne fait pas confiance au mec qui écrit le script derrière (shell ou post install). Par contre, le paquet de la distrib a l'avantage de ne pas pourrir complètement ta distribution. Tu peux le désinstaller. Rien que ça, c'est un énorme avantage.
[^] # Re: Linux for desktop !!!
Posté par Mildred (site web personnel) . En réponse au journal des paquets Snaps dans Ubuntu. Évalué à 1.
Surtout avec fpm
[^] # Re: la politique c'est la vie
Posté par Mildred (site web personnel) . En réponse au sondage Pour ou contre le hors sujet sur LinuxFr.org ?. Évalué à 4.
Il semble du moins assez clair que le logiciel libre porte des valeurs politiques, même si vous n'êtes pas d'accord sur lesquelles.
[^] # Re: la politique c'est la vie
Posté par Mildred (site web personnel) . En réponse au sondage Pour ou contre le hors sujet sur LinuxFr.org ?. Évalué à 5. Dernière modification le 11 avril 2016 à 12:17.
La politique au sens large n'est pas spécifique a un pays. La politique c'est aussi discuter du fonctionnement de la société au sens large. C'est pas juste un bulletin dans une urne. C'est très réducteur comme approche.
Et le fonctionnement de la société est un sujet qui est loin d'être spécifique a un pays en particulier.
Sans compter que le logiciel libre au sens de la FSF est un sujet hautement politique en lui même.
# Seconde page
Posté par Mildred (site web personnel) . En réponse au journal LinuxFr.org n'aime pas discuter du hors sujet [titre réécrit]. Évalué à 5.
Pourquoi ne pas réhabiliter les journaux de seconde page ?
http://linuxfr.org/suivi/journaux-de-seconde-page-dans-la-colonne-de-gauche
A savoir que je pense qu'un journal peut très bien être dans la seconde page mais être très pertinent, alors qu'il peut y avoir des journaux de première page moins pertinents. C'est a mon avis une problématique orthogonale.
La première page contiendrait les journaux dans le thème, la seconde page, les journaux bookmark ou HS. La première page a une prévisualisation extensive, alors que la seconde page ne prévisualise que ~5 lignes dans la colonne de gauche (25 mots max).
[^] # Re: [HS] Wayland est un protocole
Posté par Mildred (site web personnel) . En réponse au journal Où est le "vrai Linux"?. Évalué à 3.
C'est effectivement une remarque très juste. Si je ne me trompe pas, on a actuellement plusieurs implémentations des interfaces wayland : weston, enlightnment, gnome-shell, kwin. Rien ne garantit qu'ils fonctionnent de manière identique ou qu'ils implémentent exactement les mêmes protocoles.
[^] # Re: RMS a raison
Posté par Mildred (site web personnel) . En réponse au journal Où est le "vrai Linux"?. Évalué à 1.
Le problème avec GNU/Linux, c'est que la distribution linux a typiquement un peu d'autres trucs que juste les soft GNU. Dans le désordre, on a l'init (sysv, systemd), udev, Xorg (ça, c'est vraiment pas un projet GNU avec une licence pareille)…
Du coup, je trouverait ça logique de l'appeler GNU/Xorg/Linux (l'init étant tellement proche du noyau linux qu'il peut y être assimilé).
[^] # Re: Même problématique
Posté par Mildred (site web personnel) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
C'est principalement un intérêt personnel, après cela n'empêche pas mes collègues de s'intéresser a ce genre de choses également.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Mildred (site web personnel) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
Pour ma part, je vois un inconvénient principal : on devient dépendant du serveur qui maintient notre JID. Que ce soit le nôtre ou pas. Typiquement, j'ai un compte sur jabber.fr, que je n'utilise plus, parce que les certificats SSL n'ont pas été renouvelés. La migration vers un autre serveur est trop coûteuse pour que j'en voit l'intérêt.
Comparé a IRC, peu importe le serveur sur lequel je me connecte, ça marche toujours aussi bien. Alors certes, IRC n'offre pas le même service, mais finalement ça me convient mieux.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Mildred (site web personnel) . En réponse au journal Partage: de ownCloud (décentralisé) à Syncthing (distribué). Évalué à 2.
Tout a fait, et ça peut aussi poser des problèmes sur les nœuds a la périphérie du réseau comme les appareils mobiles qui n'ont pas forcément la bande passante ou la batterie nécessaire.
Par contre, malgré cela, il faut tout de même tendre vers du distribué dans le sens ou chaque nœud fait partie intégrante du réseau. Dans le cas de synthing, on a le choix de ne pas avoir de serveur (et donc une dispo des données moins importante) ou monter (ou louer) un serveur pour avoir une dispo plus importante. Le choix est possible et est fait en toute connaissance de cause.