Sous ce titre un peu provocateur, il s'agit d'une vraie question.
Les explications très claires de Benjamin Bayart sur le réseau montrent bien de la différence entre un réseau centré type téléphonique et des fondements d'un réseau à commutation de paquet type internet. L'une des différences de base étant que dans le premier l’intelligence est dans le réseau alors que dans le second l'intelligence est dans la périphérie. Il explique alors très bien en quoi cette caractéristique a permis l'évolution massive et rapide de l'utilisation d'internet, car il n'y a pas d'a priori technique, et que chacun peut développer un service dans son coin qui sera immédiatement disponible partout. (avec un réseau centré, il faut déployer le nouveau service sur tout le réseau avant de pouvoir le proposer).
Maintenant, si on pense aux applications "cloud" comme la plupart des serveurs de mail type gmail, bien qu'elles s'appuient sur une technologie IP, on peut légitimement se poser la question de l'impacte qu'elles ont sur les possibilités d'évolution. Dans la récente discussion sur l'autohébergement des emails, il est montré plusieurs fois qu'un des problèmes importants est le classement en spam de ses emails s'ils ne sont pas envoyés par l'un des gros serveurs d'emails de la planète. Ainsi, à vouloir gérer les spams dans les serveurs et non chez les clients (pour optimiser les résultats) on a concentré les zones d'intelligences (les serveurs) aux dépens des clients. Cela déclenche des solutions génériques et non plus spécifique (et offre en plus la possibilité de faire des choix autres que techniques, le nombre de personnes à influencer / persuader étant faible). À l'échelle des applications (et non du réseau) on a donc bien une similitude entre un serveur qui à l'origine devait transporter / transférer (d'ou le nom des programmes et protocoles MTA, SMTP) et un serveur qui fait maintenant des choix à la place du client.
Tout cela n'a pas directement d'impact sur le réseau, car c'est bien IP qui fait toujours le lien. Cependant, en terme d’influence, il me semble que c'est loin d'être négligeable. Les gros fournisseurs peuvent décider de mettre en place des règles qui les arrangent (comme de jeter les emails qui n'ont pas été émis par leur liste blanche). Ils prennent donc l'habitude de prendre des libertés avec leur rôle, voir avec les outils (protocoles). Le jour où des réflexions sont menées sur la gouvernance d'internet, comme ce sont de gros acteurs, ils sont les premiers à être interrogés. L'interopérabilité, le respect des protocoles, le respect de certains principes n'étant plus pour eux des problèmes quotidiens, il y a peu de chance que ces aspects soient considérés comme des points clés dans leurs commentaires. L'impact sur le réseau lui-même peut alors être énorme.
En conclusion, je me demande donc si la position de dominance que crée les applications "cloud" centrées, n'est elle pas un danger majeur pour l'outil qui leur a permis de naitre (Internet) par simple effet retour?
# Toujours le même problème: centralisation
Posté par Maclag . Évalué à 10.
Finalement, on tourne toujours en boucle autour de la même problématique: l'hyper centralisation.
Ce n'est pas le "cloud" ici le problème, mais c'est que le "cloud" est géré par de très grosses sociétés sur lesquels les utilisateurs n'ont que peu de contrôle ou d'influence.
Si les services étaient éclatés en multiples petites entités, même sans aller jusqu'aux amateurs et auto-hébergés, mais un écosystème tel que l'époque des multiples petits FAI locaux, tout le monde serait obligé de bosser ensembles, et la porte aux coups tordus serait plus lourde.
Moins il y a d'acteurs, moins il y a de concertation sur les standards. Quand il n'y a plus qu'un acteur, il fait la pluie et le beau temps.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
La neutralité du Net est donc importante.
Il faut aussi de battre pour remettre en avant le pair à pair. C'est une des raisons de soucis de la saturation des réseaux aujourd'hui. Tout le monde va au même point. Seul le pair à pair tire vraiment partis du réseau. Pour cela, il faut le remettre en avant au niveau de nos gouvernement mais aussi des applications. Avoir du pair à pair qui marche bien.
Avec tahoe, on peux avoir une très grande résistance au panne et être répartis. On pourrait avoir un système de sync des données de type paramètrage, bookmark… sur le réseau. A chacun d'allouer autant d'espace chez lui pour les autres que ce qu'il occupe ailleurs.
Bref, je trouve qu'il y avait une grande activité autour du pair à pair il y a quelques années (notamment pour faire des programmes le plus court possible afin de montrer que son langage était mieux que celui du voisin) et que c'est un peu retombé sauf bitcoin qui nous ramène un peu dans le sujet.
[^] # Re: Toujours le même problème: centralisation
Posté par claudex . Évalué à 4.
Le problème du P2P, c'est la sécurité des données. Si un admin de Google peut lire mes mails, ce n'est pas grave, je ne le connais pas, il n'y a pas de raison qu'il le fasse (et puis, je n'ai rein à me reprocher). Si mon voisin peut les lire, le jour où je fais un peu trop de bruit, il pourra publié que je suis sous Linux et mon image de jeune cool sera détruite à tout jamais.
Et c'est le raisonnement de beaucoup de gens. Demandez-leur de raconter à leur voisin tout ce qu'ils ont publié sur Facebook et vous verrez leur tête.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
XMPP est capable de faire du P2P. Il utilise certes un serveur pour négocier une session (ce qui peut être un atout), mais il est envisageable qu'il soit possible de s'en passer. Du coup pour reprendre ta liste:
email : XMPP (cf mon biller à ce sujet)
VPN : free-lan
audio/vidéo : XMPP (Jitsi par exemple, même si perso j'ai toujours eu des soucis avec). Linphone bouge beaucoup et est dispo sous de nombreuses plateformes (web, GNU/Linux, Android, etc)
chat : du jabber en pair à pair ? ==> C'est déjà le cas: soit avec une négociation de session passant par le serveur (jingle), soit en local (http://xmpp.org/extensions/xep-0174.html). Pourquoi pas un jour se passer de serveur même en dehors du réseau local ?
partage : XMPP (jingle), même si y'a encore du boulot de ce côté
podcast pair à pair: Du streaming ? Là encore je dirais jingle à la rescousse, mais à voir je ne me suis pas encore intéressé à ce problème.
annuaire sur DHT: plus facile sur le papier qu'en pratique. Nous avons commencé un mini annuaire XMPP qu'on espère pouvoir rendre distribué…
Bref il y a des tas de projets qui demandent du temps et/ou des améliorations.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
podcast : freecast : http://www.freecast.org/userguide/introduction.html Cela permet la diffuson audio (voir vidéo) en P2P. Pas besoin d'un super serveur en central.
VPAN : je pensais effectivement à free-lan. Je ne sais pas si c'est toujours super actif ?
audio/vidéo : Je pense à un vrai réseau P2P… comme skype au début (maintenant, les serveurs sont tous Microsoft). Pas un truc sur H323 ou SIP qui sont des horreurs au niveau port et ne fonctionneront jamais en P2P décentralisé à mon avis.
Partage : je pensais plus à la mule et tout ce genre de réseau… Mais perso, j'aime beaucoup XMPP ;-)
Bref, je pense que toutes les briques sont quasi là. A améliorer, à mieux homogénéisé, à rendre encore plus facile d'accès pour l'utilisateur lambda, à promouvoir.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Toujours le même problème: centralisation
Posté par diorcety . Évalué à 1.
VPN: Il y a aussi SocialVPN
Partage: Avec ton VPN tu peux surement utiliser D-LAN pour faire du P2P en dessus
[^] # Re: Toujours le même problème: centralisation
Posté par NeoX . Évalué à 4.
bah email c'est deja decentralisé non ?
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 26 avril 2014 à 22:38.
Oui, mais SMTP a de nombreux problèmes, et XMPP en règle beaucoup. XMPP est unicode de base, il n'est pas possible (théoriquement) d'usurper une adresse alors qu'avec qu'SMTP il suffit de la changer, pas de limite pour les pièces jointes (enfin il faut définir comment les envoyer, mais c'est juste une XEP à ajouter), liste de contacts (roster) déjà intégré, etc. Et avec passerelle + le jid qui ressemble à une adresse courriel, la transition est facile.
Un des buts de SàT est de fournir ce qu'il faut pour remplacer le courrier électronique par XMPP.
[^] # Re: Toujours le même problème: centralisation
Posté par claudex . Évalué à 3.
Oui, enfin, je ne doute pas que si ça se répand, les limites arriveront.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 26 avril 2014 à 23:20.
Tu peux avoir des quotas, c'est une chose. Mais la plupart des MUA t'empêchent d'envoyer une pièce jointe supérieure à 5, 10 ou 15 Mio, alors que de nos jours c'est quand même pas énorme. Moi j'ai mon propre serveur de courriel, je n'ai pas de quota, et pourtant on n'a pas pu m'envoyer un fichier de ~70Mio tout à l'heure.
En plus de ça XMPP est capable de faire un transfert en P2P (bon là faut les 2 machines allumées en même temps bien sûr, donc on s'éloigne du courrier électronique).
Edit: et sans oublier la perte due au passage en base64
[^] # Re: Toujours le même problème: centralisation
Posté par claudex . Évalué à 3.
70Mo, je n'ai jamais essayé mais 50Mo sans problème. Mais les pièces jointes limitées à 10Mo, ce n'est pas les MUA, ce sont les administrateurs qui le décide, et s'ils le décide pour le mail, je doute qu'ils ne fasse pas de même pour XMPP.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
ça peut être le MUA ou le MTA (en pratique la limite vient souvent du MTA parce qu'il doit stocker la pièce jointe, mais elle peut être mise dans le MUA en prévision), mais peut importe. Le truc est que le courrier électronique n'est pas fait pour transférer des pièces jointes, c'est un bricolage qui a été ajouté dessus (MIME) et on se retrouve avec plein de problèmes: en particulier cette fameuse limite, et l'augmentation énorme de la taille du fichier. Tu as peut-être pu envoyer 50 Mio à quelqu'un, mais rien ne garantie que ça se passera aussi bien avec une autre personne.
XMPP lui a des XEPs dédiées au transfert de fichier, même s'il n'y en pas qui définissent une pièce jointe, il suffit d'en ajouter une, il a ce qu'il faut pour créer une canal dédié et faire un transfert efficace. Bref, on a une séparation propre de la pièce jointe, et pas un plat de spaghettis à la sauce MIME.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toujours le même problème: centralisation
Posté par gnx . Évalué à 2.
Prière de fournir une source quant à une éventuelle limite de taille dans MIME.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1.
Qui a parlé de limite de taille dans MIME ?
[^] # Re: Toujours le même problème: centralisation
Posté par gnx . Évalué à 2.
Goffi :
La taille d'un courriel n'étant pas limitée par SMTP, n'étant pas limitée par le format courriel, n'étant pas limitée par MIME, il se peut que vous arriviez à la conclusion qu'il n'y a pas d'autres limites aux pièces jointes que celles fixées arbitrairement par les admins de chaque serveur, qu'il n'y a pas de relation avec le(s) protocole(s) utilisé(s), et que s'ils sont logiques, il n'y a pas de raison qu'ils fixent des limites différentes en fonction des protocoles utilisés.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1.
Je dis que les pièces jointes sont un bricolage par dessus SMTP (qui est MIME), et que SMTP n'étant pas adapté au transfert de fichiers, on a de nombreux problèmes avec à cause de ça.
La taille des pièces jointes n'est effectivement pas limitée par SMTP ou MIME je n'ai jamais dis le contraire, mais l'architecture du réseau, son historique, le fait que les messages soient stockés par chaque MTA fait qu'en pratique c'est limité, soit au niveau du MUA, soit d'un MTA.
Et le protocol est tout à fait lié à ces limites, outre son historique, le fait que les messages soient stockées par les MTA, et que la taille des fichiers soit beaucoup augmentée à cause de base64 fait qu'en pratique on limite les tailles à des valeurs ridicules de nos jours.
XMPP envoit le fichier par un canal séparé, rendant ces limites inutiles. Il est toujours possible de mettre des quotas, ça personne n'a dit le contraire, mais rien n'empêche que si je m'auto-héberge on m'envoit un fichier de 3 Go. Essaye de faire pareil avec juste du SMTP. En plus de ça, XMPP gère le P2P, et la plus question de quota.
P.-S.: ohhh un nouveau dessin, c'est lié au nombre de commentaires dans un fil ? Rigolo :)
[^] # Re: Toujours le même problème: centralisation
Posté par gnx . Évalué à 4.
+33%. C'est pas négligeable, mais ça ne change pas l'ordre de grandeur.
Si je suis mon propre MTA/MDA et que mon destinataire est son propre MTA/MDA, il n'y a pas d'intermédiaire imposant ses propres règles non plus, quelle est la différence ?
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui c'est sûr, si t'as un cas idéal où tout le monde laisse tout passer, et si t'acceptes tout le bordel qui va avec (base64, stockage du fichier à chaque étape, transfert à recommencer depuis le debut si ça foire, et y'en a sûrement d'autres que j'ai pas en tête), ça peut marchoter. Mais en pratique ça n'arrive pas, j'ai eu le cas hier avec le fichier de ~ 70 Mio qu'on a essayé de m'envoyer depuis un compte gmail, et comme déjà dit je gère mes propres serveurs, c'est pas de mon côté que ça coinçait (enfin j'ai pas vérifié, mais a priori je n'ai rien mis dans ma conf pour bloquer quoi que ce soit).
Avec XMPP le fichier passe par un canal dédié, peut être stocké ailleurs que le reste du message, y'a pas d'augmentation de taille, et même si y'a un quota au milieu tu peux toujours faire un P2P. Et je passe tous les autres problèmes de SMTP.
Je ne dis pas que XMPP est un protocole parfait, il a ses défauts, mais je dis qu'il est un excellent candidat pour remplacer SMTP, et probablement le meilleur candidat actuel.
[^] # Re: Toujours le même problème: centralisation
Posté par gnx . Évalué à 1.
Okay, donc avec XMPP aussi, si je comprends bien, ça marche dans un cas idéal, à savoir le cas où l'expéditeur et le récepteur sont connectés au même moment.
Base64 : ça dépend du MUA (si son auteur a décidé de forcer à encoder en base64) car ça doit faire 15 ans que les MTA sont capables de passer du 8-bits sans accroc.
Stockage intermédiaire : si tu n'es pas dans le cas idéal en XMPP, il faut bien que ça soit stocké sur un serveur. Donc même raison pour mettre des quotas qu'en SMTP.
Reprise de transfert : bien, mais ça implique que les serveurs stockent pendant un certain délai les morceaux de fichiers dont le transfert est inachevé. Devrait influer négativement sur les quotas.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Euh non, ça marche dans le cas normal, et si jamais tu as un quota sur le serveur de fichiers, tu peux passer par un autre, ou faire un envoi P2P, qui est aussi un cas normal mais qui demande à ce que l'autre soit en ligne.
2 personnes en ligne en même temps c'est beaucoup moins rare que de te retrouver dans un cas où tout le monde gère sa propre chaîne de courriel, et que tout soit configuré sans limite.
ok pour le coup de la taille, si toute la chaîne accepte du 8 bits ça fonctionne.
Oui il faut que ça soit stocké, mais une seule fois, pas à chaque MTA.
Les quotas tu es dépendant du serveur de fichiers que tu choisis. En SMTP tu es dépendant de tes MUA/MTA que tu peux maîtriser, mais aussi de ceux de ton correspondant.
Si Thunderbird stocke les gros fichiers sur des services externes et envoi le lien dans le message, c'est qu'il y a une raison…
[^] # Re: Toujours le même problème: centralisation
Posté par gouttegd . Évalué à 3. Dernière modification le 28 avril 2014 à 12:52.
Bah vérifie alors, parce que si toi tu n’as « rien mis dans ta conf », la configuration par défaut de ton serveur peut très bien être de limiter la taille d’un message.
Avec Postfix par exemple, la configuration par défaut limite à ~10 Mo.
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 1.
peu importe (j'ai un exim avec à peu de choses près le conf de base, c'est possible que ça soit limité *), ce que j'indique c'est qu'avec le courrier SMTP s'il y a un élément limitant dans la chaîne t'es marron. Je viens de tomber sur ça par exemple: http://www.outlook-apps.com/maximum-email-size/
Le tableau indique que des MUA (ici outlook et windows live mail, il n'y en a pas pour Thunderbird) imposent des limites, et tous les serveurs cités en imposent aussi, sauf si ça passe par un service externe.
* en effet ça semble être limité à 50 Mio, mais de toute façon la limite de gmail étant apparemment 25 Mio, mon MTA n'a pas été concerné.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 10.
Le souci avec XMPP et les technos qui vont autour, c'est qu'elles sont en permanence en retard sur tout ce que propose la concurrence.
Tu as listé 7 "services", et tu as mentionné que 5 ne sont pas aboutis.
Pendant ce temps, Google, Facebook et Microsoft ont habitué ou sont en train d'habituer leurs utilisateurs au tout centralisé.
Avec XMPP, c'est toujours la même chose:
Quand on nous dira que "ça marche pour presque tout le monde", le monde en question sera passé à autre chose et du côté XMPP on nous dira que pour la suite "ça marche pas encore, mais on prend le temps de faire un truc propre".
Je ne vais pas reprendre la liste, mais par exemple: Linphone/Jitsi: ça fait des années que la vidéoconférence est un service abouti chez MS/Skype, chez Google, et FB le propose aussi.
La bataille pour la vidéoconf est terminée depuis longtemps et XMPP s'est pris une raclée faute à du "presque bientôt prêt" qui a lassé les plus patients des enthousiastes.
A une époque, une occasion en or s'est présentée: Google s'est intéressé au projet et au protocole. Grand mal lui a pris: combien de temps s'est-il écoulé entre l'implémentation première de Jingle par Google (en VoIP à l'époque) et la publication des specs Jingle?
Il s'est passé 4 ans!
En 4ans, des technos sont adoptées et abandonnées. En 4 ans, des empires se créent et d'autres s'effondrent.
4ans, c'est ce qu'il a fallu à FB pour passer d'un réseau universitaire sur invitation à plusieurs centaines de millions d'utilisateurs!!
Si au lieu de passer ces 4 années à chercher à écrire la RFC parfaite le projet avait bossé sur les autres sujets dont tu parles, XMPP serait peut-être encore dans la course, et les hautes instances de Google auraient sûrement été plus réticentes à l'idée d'abandonner XMPP pour Hangout.
J'ai presque pitié pour Google qui est censé évoluer dans le marché grand public, un marché redoutablement dynamique et changeant, avec le boulet XSF au pied. Ils auraient dû carrément forker le protocole.
Oui, ça aurait gueulé: "Google forke XMPP!! Qu'est-il arrivé au Don't be evil?". Mais c'est quoi le pire? Un fork d'XMPP par Google, avec un espoir de voir la XSF comprendre pourquoi ils sont obligés de le faire, ou la situation actuelle: Google qui va abandonner simplement XMPP?
XMPP est peut-être un super protocole, mais il est surtout suicidé par la lenteur de la XSF!
[^] # Re: Toujours le même problème: centralisation
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Euh non, j'ai repris une liste de 7 « services », et j'ai dis que XMPP répondait déjà à 4 d'entre eux (email, audio/vidéo, chat et partage - même si pour ce dernier il y a effectivement encore du boulot -).
Attention j'ai cité Linphone pour l'audio/vidéo, mais Linphone n'utilise pas XMPP ! Ça utilise SIP. Jitsi lui utilise les 2, et effectivement j'ai eu des soucis avec mes essais, maintenant je teste assez peu ça, il y a probablement des implémentations qui tournent très bien. La vidéo conférence est quand même un cas très particulier et très complexe, et même en sortant de XMPP, il y a peu voire pas de logiciels libres qui sont très bons là dedans (pour l'audio il y a mumble qui s'en tire bien je crois, et avec l'audio uniquement j'ai de bon résultats avec Linphone).
Bon y'a Tox qui est à la mode alors qu'il ne fait… que du chat pour le moment (et encore, même pas sur qu'il le fasse bien).
Ce n'est pas choquant du tout pour l'élaboration d'un standard. Ça n'empêchait pas les implémentations avant, juste qu'il y avait des risques de devoir les modifier avant la spécification finale. Au contraire, ça serait même plutôt mauvais signe que ça aille trop vite (il faut du temps pour discuter et tester les implémentations).
Les standard c'est une chose, les implémentations une autre. XMPP est toujours dans la course et de toute façon ça ne m'intéresse pas de courrir derrière les modes du moment, ni d'avoir des « gros » (quel intérêt de la décentralisation et de la fédération si tout le monde est chez Google ?). On ne sait pas les raisons internes de l'abandon (pas tout à fait effectif d'ailleurs) de XMPP pour Gtalk, mais c'est peut-être pour de basses raisons anti-concurrence (Microsoft commençait à inclure le support XMPP pour pouvoir communiquer avec GMail, notamment dans Skype et il me semble qu'il y avait une histoire avec Outlook aussi).
Je reproche surtout à la XSF de ne pas mettre les priorités au bon endroit (il s'intéressent plus à l'internet des objets qu'à corriger pubsub en ce moment), mais en même temps je n'ai pas encore pris le temps de travailler moi-même sur les XEP ni de participer en dehors de quelques messages sur les listes. Donc je critiquerai vraiment quand j'aurai tenté des trucs si la XSF me bloque, mais je n'en suis pas là.
Après tous les effets de mode, c'est plus ça qui tue les projets dans l'œuf à mon avis. Tout le monde s'est rué sur Diaspora à une époque parce qu'on en parlait, oubliant les projets qui existaient et dont plusieurs existent toujours maintenant. Diaspora est toujours actif depuis que c'est vraiment communautaire (j'ai discuté avec un dév récemment entré dans l'équipe aux JDLL), mais on n'en parle plus parce que c'est plus à la mode. Aujourd'hui la mode est à bitmessage ou twister (bitmessage c'est peut-être intéressant sur le plan technique/théorique, mais j'ai franchement du mal à imaginer un truc sérieux qui tourne avec), demain ça sera oublié pour autre chose. Enfin bref, faudrait peut-être passe un peu moins de temps à s'esclaffer sur twitter sur les trucs à la mode, et plus à aider les projets qui manquent de bras…
[^] # Re: Toujours le même problème: centralisation
Posté par Funigtor (site web personnel) . Évalué à 1.
Le problème de Mumble c'est, bien qu'il soit vraiment bon, d'être du même type que Teamspeak. On est loin d'un équivalent de Skype, ce n'est pas le but du projet.
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je ne vois pas la différence. Avec Mumble, tu parles des copains. Avec Skype, tu parles avec des copains, mais c'est pas pareil?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Funigtor (site web personnel) . Évalué à 1.
Avec Skype, tu appelles tes copains; avec Mumble tu te connectes au serveur où sont tes copains déjà en train de parler. Cela implique que tes copains soient déjà en train de parler (ou en tout cas près à le faire s'il il n'y en a qu'un de connecté sur le serveur) pour les joindre là où Skype va avoir un fonctionnement plus proche d'un téléphone.
De plus, Mumble nécessite un serveur commun qui transmet utilisateurs et flux vocal là où un équivalent à Skype pourrait s'en passer avec contact sur un serveur puis connexion directe lors d'un appel. (Hors cas de conférence à plusieurs où là un utilisateur joue le rôle de serveur (en tout cas c'est comme ça sur Skype).) Le résultat est au final le même mais la façon d'y arriver diffère.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 7.
Avec Skype, tu as un gestionnaire de contacts, un téléphone, un système de vidéoconférence, un système de partage d'écran, un système de chat, tu peux dialoguer avec une ou plusieurs personnes sans te demander à l'avance si ce sera un simple dialogue ou un salon.
Je ne me suis jamais retrouvé derrière un pare-feu que Skype ne sait pas traverser, c'est simple à utiliser et assez intuitif pour que mes parents n'aient besoin de personne pour lancer ou arrêter la vidéo etc.
Tu peux maintenant aussi déposer des messages vocaux et vidéo en l'absence des gens, te faire un vrai numéro de tél qui renvoie sur ton compte Skype.
Mumble fait tout ça?
Non, alors Mumble et Skype, c'est pas pareil.
Pour tous ceux qui ne veulent installer qu'un seul client pour la communication avec des humains (genre, au hasard, les 90% d'utilisateurs dans le monde qui se fichent de la liberté et veulent juste que ça marche sans tracas), que fait Mumble que Skype ne peut pas faire?
Existe-t-il ne serait-ce qu'un seul logiciel Libre qui sache faire tout ça et qui soit prêt à utilisation "en prod" là maintenant tout de suite?
Pas à ma connaissance, c'est pas près d'arriver à mon avis, et d'ci à ce que ça arrive, Skype aura introduit d'autres fonctionnalités dont ses utilisateurs ne sauront plus se passer.
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Tu as bien de la chance.
La vraie question, c'est que peut faire Skype pour nous libristes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 4.
Peut-être, ou pas. Skype a toujours été très bon et reconnu très bon là-dedans.
Ca ne veut pas dire que personne au monde n'a jamais eu de problème, mais tu peux m'indiquer un équivalent Libre qui fait mieux?
La réponse est: rien!!
Il n'y a rien à attendre de Skype pour les Libristes! Même le client Linux fermé est au mieux dans les abysses de leurs priorités pour ne pas dire complètement à l'abandon. Les conditions d'utilisation ne valent pas mieux que ce que faisait MSN à l'époque.
Qu'a fait le Libre pour le grand public en termes d'outils de communication?
Proposer une fatras de clients tous pas finis/incomplets et/ou compliqués à installer et/ou à utiliser, faire des promesses que "bientôt on aura tout un tas de fonctionnalités", en boucle pendant des années.
Qu'a fait le Libre pour Skype?
Lui laisser un grand boulevard sans aucune compétition pendant plusieurs années pour s'assurer son expansion? Ecoeurer les utilisateurs qui espéraient l'émergence d'une alternative Libre crédible?
Aujourd'hui encore, je suis bien content d'utiliser Skype qui me permet de communiquer avec tout le monde, et pas seulement des Libristes engagés et prêts à faire de gros efforts pour que ça marche:
-je m'en sers depuis des années pour faire de la vidéoconf avec ma famille
-je m'en sers depuis des années pour bosser avec des collègues distants
-je m'en sers depuis des années pour presque tous les entretiens distants que j'ai eus
Et tout ça a toujours fonctionné sans aucun effort particulier autre que d'installer le client et ouvrir un compte. C'est au point depuis des années!
Aucun de mes interlocuteurs (famille, collègue, autres contact) ne m'a jamais demandé d'installer Jitsi, ou Linphone, ou autre. La première fois qu'on m'a demandé d'utiliser autre chose que Skype pour de la VVoIP, c'était y'a pas 2 semaines, et c'était "est-ce qu'on peut faire un appel sur Google?".
Firefox a percé chez le grand public. VLC est connu du grand public.
Aucun client Libre pour un outil de communication n'a jamais eu ne serait que 10% de ce succès, et je ne vois pas ça changer dans un avenir proche. Les problèmes sont toujours là, les mêmes depuis des années! Même cause, même conséquence.
Si Skype est remplacé dans l'année qui vient, il le sera par une autre solution propriétaire complètement fermée et tout aussi peu respectueuse de la vie privée, mais qui aura un avantage indéniable sur n'importe quelle solution Libre: ça marche de suite sans se faire chier, et ça remplit tous les besoins!
Et quand cette solution émergera, on en sera tout juste à un équivalent fonctionnel à Skype, qui aura donc les difficultés suivantes:
-peu d'attrait par rapport à Skype (l'argument "Libre" n'est pas efficace sur 90% des utilisateurs)
-déjà en retard, parce que si Skype est remplacé, c'est parce que le nouveau venu aura quelque chose de très intéressant en plus que Skype n'a pas intégré, et l'alternative Libre non plus!!
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
C'est fou cette tendance à vouloir absolument se justifier qu'utiliser un logiciel non libre, ce n'est pas sale :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 3.
C'est fou ce refus d'admettre que dans le domaine, le Libre est en retard sur tous ses concurrents proprio et c'est pas près de changer.
On a droit à tout:
-En fait, t'en as pas vraiment besoin, de cette possibilité
-Ah oui mais ça c'est pas bon pour la sécurité! (sinon bien évidemment on aurait des solutions au poil là-dessus aussi, on y croit à mort)
-C'est pas que le Libre n'a pas d'alternative satisfaisante, c'est que toi tu cherches une excuse pour utiliser un logiciel proprio
Que veux-tu que je te dise? Que j'utilise Skype par conviction idéologique? Que je l'utilise pour le principe? Pour me la jouer "nan mais je suis pas vraiment Libriste", ça marche sûrement pour draguer sur linuxfr? Parce que j'aime bien troller?
Ça t'emmerde tellement d'admettre que le produit est juste très bon et que tu n'as encore rien à mettre en face?
Tandis que toi, tu es un vrai Libriste: tu n'as aucun firmware proprio sur ta machine, tu n'es inscrit sur aucun service qui ne soit pas 100% ouvert et transparent, je suppose que tu n'as pas de téléphone, parce qu'on ne sait pas trop ce qui tourne sur ces petites bêtes?
Comme je le disais: le Libre est en retard, et la mentalité de certains garantit la suprématie des solutions fermées pour encore un bon moment.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je suis d'accord pour dire que la visio-conférence marche pas bien sous GNU/Linux. Le H323 est très complexe, le SIP pas mieux. Pour faire de la bonne visio (de bureau), il faut un bon codec temps réel, c'est pas pour rien que le H264 et le H265 viennent de la visio. D'ailleurs, Google utilisait pour son service en ligne le codec ultra performant de Vidyo.
Ensuite, il faut multiplexé les vidéo (avec le son) en temps réel. En effet, je parle ici de visio à plusieurs site. Soit on a un pont hardware (visio de salle), soit par exemple Vidyo s'appuie sur plusieurs serveurs pour faire cela. Dans tous les cas, il faut toujours privilégier le son devant la vidéo.
Bref, les briques arrivent petit à petit mais il faut être honnête, c'est très loin d'être du niveau et de la simplicité de Skype. Cela sera correct quand on pourra se connecter en vidéo à un salon jabber ou a un autre système P2P… A un moment, il y a eu un projet d'étudiant VLVC qui semblait super mais n'a pas dépassé le stade du PFE. J'ai vu des trucs qui se profile via le WebRTC sur Firefox qui semble toutefois prometteur.
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est là où on ne se comprends pas: je trouve Skype mauvais indépendamment de sa licence. Je ne l'ai pas vu souvent marcher en entreprise (le soit disant passage des firewalls est une blague face à des sysadmins nazis/compétents) et pour jouer, il est moins bon que Mumble.
Après pour appeler Tata Michez au Pérou, c'est peut être bien, mais je ne parle pas espagnol :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 1.
Je me répète: je ne l'ai jamais vu pas marcher.
Je n'ai cela dit jamais eu à gérer de sys admins nazis/compétents, et c'est tant mieux parce que je ne me vois utiliser un logiciel interdit par la boite. Si on t'interdit les logiciels de communication, tu t'en sers toi?
Et je ne vais certainement pas juger de la qualité d'un logiciel de communication audio/vidéo/autre sur sa capacité à passer outre les tentatives de blocage à son encontre!
Il marche déjà très bien par défaut, il ne s'offusque pas si je passe par un VPN, encore une fois: je n'ai jamais vu Skype coincé!
Oui mais pour appeler et voir la famille en France quand tu es en Asie, ou pour appeler et voir femme et enfant qui sont en Asie quand t'es en déplacement pour 1 mois (et plus si affinités…) en Amérique du Nord, c'est rudement pratique!
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Tu ne l'as jamais vu, donc ça n'est pas possible. C'est logique :-)
Tu dois aussi avoir accès à des prostitués pour pas cher quand madame est loin! C'est rudement pratique :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Un sysadmin compétent et super chiant n'a rien à voir avec un nazis. Merci de ne pas utiliser ce mot à tord et à travers.
https://fr.wikipedia.org/wiki/Nazis
[^] # Re: Toujours lemême problème:centralisation
Posté par Juke (site web personnel) . Évalué à 3.
une pile TCP IP ?
[^] # Re: Toujours lemême problème:centralisation
Posté par Anthony Jaguenaud . Évalué à 3.
Ça marche au dessus de http ?
Oui… tout passe par http.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 3.
Je crois me souvenir que certains projets avaient clairement annoncé qu'ils attendaient que ça se stabilise avant d'implémenter, pour éviter de devoir changer des choses ensuite, ressources limitées, tout ça.
Et tu es en train de confirmer que pour rester dans la course, il faut faire cavalier seul et pas passer par des standards ouverts: on arrive plus vite à un résultat fonctionnel. D'ailleurs, qui a décidé d'utiliser Jingle en dehors de Google qui en est à l'origine et des clients XMPP Libres qui cumulent à eux tous une PDM dérisoire?
Quel intérêt d'avoir le meilleur système du monde si personne ne s'en sert à part les potes geeks? (et perso, j'ai peu de potes geeks…)
La vidéo, c'est pas "une mode du moment", c'est devenu une fonctionnalité majeure. Le partage d'écran, je m'en sers très souvent au boulot.
Faudrait voir à pas qualifier d'effet de mode toutes les avancées sur lesquelles les clients Libres n'arrivent pas à suivre.
Diaspora est un projet qui n'avait pour lui que le "hype". Si on en croit les billets de l'auteur de Friendica, Diaspora, ce sont des "p'tits jeunes" qui se sont largement surestimés (je suis peut-être biaisé, j'avais déjà cette impression avant quand ils faisaient leur levée de fonds)
C'est une tragédie que Diaspora ait pu lever autant de fonds alors qu'effectivement, de nombreux projets plus sérieux en sont encore au temps libres de leur auteur.
On en entend plus parler parce qu'après la désillusion qui a suivi, nombreux sont ceux qui ne veulent tout simplement plus en entendre parler.
Il faudrait peut-être que ces projets qui manquent de bras offrent une perspective plus alléchante en termes d'objectifs. Pour l'instant, je vois beaucoup de projets faits pour leur auteur et ses potes plutôt que pour toucher un public le plus large possible. Je n'ai rien contre ça, chacun fait ce qu'il veut, mais faut pas s'étonner si ça ne suscite pas l'enthousiasme des foules.
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Pas terrible pour la sécurité…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par Maclag . Évalué à 5.
Pour être sûr que je suive: est-ce que tu vas me dire que le manque en fonctionnalité dans les alternatives Libres est volontaire par souci de sécurité? Ou est-ce que tu essaies de te convaincre qu'il vaut mieux rien qu'une solution pas assez bien à ton goût?
[^] # Re: Toujours le même problème: centralisation
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je veux juste dire que partager la vue et éventuellement le contrôle d'un PC de l'entreprise via un service externe, ce n'est pas terrible pour la sécurité. Rien de plus, rien de moins.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Toujours le même problème: centralisation
Posté par claudex . Évalué à 6.
Le problème, c'est d'arriver à rendre les plus petites structures compétitive. Par exemple, quel est l'intérêt d'aller chez XXX alors que chez Google/Amazon, il y a une meilleure infrastructure, une disponibilité connue et très bonne et ce n'est pas plus cher (ou pas de manière significative). Le seul point qui pourrait changer la donne, c'est la centralisation du trafic qui ralentit les plus gros (Youtube ou Netflix), mais ça ne durera pas avant que tout les fournisseurs de contenus soient obligé de payer les FAI, et là encore, les plus gros seront avantagé par des économies d'échelle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours le même problème: centralisation
Posté par Misc (site web personnel) . Évalué à 3.
Bien sur, mais la centralisation me parait quand même assez inévitable. Il y a un avantage économique à se regrouper pour les acteurs donc soit ils le font, soit ils perdent l'avantage économique face à ceux qui le font. La mutualisation est donc naturel. Même dans le libre, quand on regarde bien.
Ensuite, le souci n'est pas la mutualisation/centralisation en soit, mais l'hyper centralisation. Et le souci n'est pas tant la centralisation que le cout pour un nouvelle entrant qui pourrait changer ça. La centralisation ne serait pas un si gros souci si quelqu'un pouvait venir et sans un effort trop couteux, combattre ça. IE, dans le cas du cloud, si tu peux concurrencer un peu les acteurs existants avec une fraction de leur moyen. Je ne sais pas à quel point c'est possible.
Depuis plusieurs mois, je lit les articles sur hacker news, qui sont assez souvent "silicon valley centric", et le destin d'une startup, c'est de se faire absorber par les gros ou de crever, ç'est assez flippant. IE, l'état "petite boite" est transitoire et personne ne le cache.
[^] # Re: Toujours le même problème: centralisation
Posté par claudex . Évalué à 4.
Il me semble qu'avec OpenStack, c'est assez facile de monter un cloud concurrent. Le probème, c'est que tu ne te distinguera pas des offres existantes, du coup, je ne sais pas comment tu peux attirer les clients. Il y a sûrement quelques niches mais rien qui ne permette de faire mieux que les gros, du moins pendant longtemps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours le même problème: centralisation
Posté par Adrien . Évalué à 4.
Beaucoup de gens envisagent de monter leur cloud, dans les grosses entreprises et institutions genre CNRS, Université, etc, notamment depuis la plus grande prise en compte de la valeur des données suite à Snowden.
Un cloud CNRS par exemple me semble tout à fait en phase avec un internet décentralisé: chaque entité ou organisation contrôle ses données, qui sont regroupées dans un lieu assez fiable, sauvegardé, accessible aux utilisateurs…
Pour les gens « extérieurs », il n'y a pas tellement de publicité, de visibilité effectivement, mais ce n'est pas le but recherché.
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Le CNRS sous traite tout désormais. Leur offre cloud s'appelle 'core', c'est du Microsoft (avec backdoors officielles) géré par BULL… Sur cette affaire, je ne suis pas fier de ma boite ;-)
[^] # Re: Toujours le même problème: centralisation
Posté par lolcat . Évalué à 2.
C'est le CNRS à l'origine de hal.archives-ouvertes.fr
C'est bien non ?
[^] # Re: Toujours le même problème: centralisation
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Oui, mais le CNRS, c'est très vaste. Cela peut parfois être vue comme un ensemble de 100 PME. Un vaste réseau… Cela n'a rien à voir avec un grosse boite ou les autres EPST qui sont bien plus centralisé.
HAL est gérée par le CCSD (qui doit être une UMS dans notre jargon : Unité Mixte de Service) qui est logé à Lyon dans les locaux de l'IN2P3. Heureusement, il y a aussi (surtout) des choses très bien au CNRS ;-)
# Cloud Personnel
Posté par NeoX . Évalué à 7.
La notion de cloud consiste à ne plus avoir d'information sur ses machines, mais de les heberger à l'exterieur.
tu peux evidemment faire la meme chose que google, ton cloud etant simplement ouvert à tes amis/familles, ou bien juste à toi et tes 5 appareils.
donc le probleme n'est pas dans le Cloud, mais dans le Cloud sous gestion de grands groupes avec les pratiques qu'on leur connait.
# Le cloud devient de plus en plus juste un espace de stockage
Posté par tanguy_k (site web personnel) . Évalué à 1. Dernière modification le 27 avril 2014 à 18:33.
Alors qu'au début du web tout était généré coté serveur et le client était idiot et ne faisait qu'afficher le HTML (=> intelligence dans le réseau), désormais on met de plus en plus d'intelligence dans le client. On parlait de site web, maintenant on parle d'application web.
Les frameworks JavaScript actuels comme AngularJS, Backbone.js, Ember.js permettent tous d'avoir un modèle de données coté client écrit en JS et de générer le HTML directement dans le client => intelligence dans la périphérie.
Retour case départ : au lieu d'avoir des applications dites "lourdes" en C/GTK+ C++/Qt Java/Swing C#/WPF, on a les mêmes applications lourdes mais écrites avec les technos web JS/HTML/CSS.
A tel point que les améliorations coté JS sont devenues le nouveau cheval de bataille des navigateurs.
Pire, les limites de JS se font maintenant sentir et chacun cherche une solution au problème : CoffeeScript, ES6, TypeScript (Microsoft), Dart (Google)…
Bref alors qu'auparavant tout se faisait sur le serveur, désormais le serveur fournit juste une API pour que le client accède aux données :
BDD <---> API fournit par le serveur avec MC (Modèle Controlleur) <---> Client avec MVC (Modèle Vue Controlleur)L'exemple de la détection des spams coté serveur est à mon avis une exception : il est simplement plus pertinent d'avoir la fonctionnalité coté serveur pour mieux détecter les spams. Mais pour tout le reste, c'est le client qui gère, pour s'en convaincre il suffit d’étudier l'API Google Calendar : l'API fournit simplement les données en les "embellissant".
Pour moi le cloud est juste un espace de stockage et tout se passe dans le client (qu'il soit natif ou web). Et c'est logique : la meilleur façon d’accéder à mes données depuis mon PC à la maison (app web), ma tablette (app native iOS/Android), mon smartphone (app native iOS/Android) et mon PC au bureau (app web) c'est d'avoir les données sur Internet au lieu de les avoir en local.
[^] # Re: Le cloud devient de plus en plus juste un espace de stockage
Posté par Zylabon . Évalué à 2.
Que le code soit exécuté sur le client ou le serveur n'a aucune importance. Si le serveur tombe, ça ne marche plus.
Personnellement, j'ai mes données en local ET sur internet. J'ai une connexion internet (et une machine grosse comme une boite d'allumette toujours en route).
Please do not feed the trolls
# Snowden and Co
Posté par Domi . Évalué à -4.
C'est toujours la même question. L'affaire Snowden nous montre que les géants de l'internet sont tous impliqués dans le scandale de la NSA.Ceci implique que le problème n'est pas que mon voisin sache ce que je fais (je n'ai jamais eu le moindre problème avec mes voisins et je ne leur ait jamais rien caché), ni qu'un admin de Goggle lise mes données (j'espère pour lui qu'il a autre chose à faire de son temps de travail que ça), ni que j'ai quelque chose à cacher (je ne me cache pas de mes voisins, devrais-je me cacher des flics?), le problème est que la majorité des gens semblent se ficher qu'une bande de fascistes corrompus passent leur temps à les espionner. En 45, ils disaient j'ai suivi les ordres, ils furent condamnés pour cela. Aujourd'hui, ils ne peuvent plus ni invoquer cette excuse éculée ni dire qu'ils ne savent pas.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.