vlamy a écrit 751 commentaires

Le bon est ici.

Non c'est hiérarchique NTP, avec des niveaux de serveurs de référence (strates) synchronisés avec plus ou moins de précision :

Tu désinstalle comment Debian ? :)

Comme Windows, c'est-à-dire en formatant le disque dur :)

En fait, c'était vraiment un troll gratuit, car j'installe Arch via un chroot et la présence d'une distribution Linux pré-éxistante sur la machine est appréciable.

C'est plutôt le partitionnement par défaut du disque qui m'importerait, notamment la présence de LVM, qui serait vraiment un plus.

Pour être vraiment honnête, dans l'idéal je prendrais une Debian pré-installée que je garderai et j'installerai Archlinux en plus.

De toute façon, être obligé de désinstaller une Debian, Ubuntu ou Suse pour mettre Archlinux dessus, ça change pas trop de désinstaller un Windows !

Pan !

Pour éclaircir tout ça, le terme pair-à-pair est apparu historiquement en algorithmique distribué, dans la fin des années 90 pour s'opposer au modèle « client-serveur », en désignant des protocoles/services dans lesquels on ne retrouve pas les rôles particuliers et classiques que sont « le serveur » et « le client ».

De plus, comme le dit l'article Wikipédia, on peut avoir un protocole pair-à-pair partiellement centralisé (Napster par exemple), mais là on retrouve un rôle particulier, celui du serveur Napster. On préfère donc généralement parler de « point de centralisation ». D'ailleurs dans la littérature scientifique sur les protocoles pair-à-pair on ne parle jamais de système (ou protocole) « décentralisé », mais plutôt « partiellement décentralisé » ou « totalement décentralisé », ce qui est plus rigoureux :)

Pour la comparaison avec le Web, qui me semble super hasardeuse, on dit généralement que le mail est un protocole décentralisé, dans le sens où chaque domaine a son propre serveur qui fait autorité, et communique avec d'autres serveurs qui gèrent d'autres domaines. C'est cette communication inter-serveur, qui n'existe pas dans le modèle HTTP, qui fait dire que le mail est un peu « pair-à-pair ». Mais à mon humble avis, c'est de l'enculage de mouches :)

Quand à la centralisation du Web, il me semble que l'on fait plutôt référence à la concentration des grosses infrastructures (serveur mail, HTTP, XMPP, etc) dans un nombre réduit de gros datacenter (Facebook, Google, Amazon, MS, etc). La décentralisation, consiste alors à tirer partie des petites infrastructures, qui, ayant moins de ressources, nécessitent la mise en œuvre de services « davantage distribués » (idéalement pair-à-pair pour éliminer tout point de centralisation) pour rendre un service du niveau de ceux hébergés par les grosses infrastructures.

Voilà My 2 cents compréhension du sujet :)

Ben je n'ai plus le nom, mais dans mes souvenirs il y avait un portail sur lequel je devais me logger, puis un genre d'applet à installer via le navigateur web. Je n'ai plus trop de souvenir, mais je me souviens avoir fait la réflexion que cela marchait bien sous Linux (< 10 minutes pour installer/configurer).

Après je n'ai pas testé la visio, seulement l'audio avec support de slide partagé, peut-être que je n'ai pas testé toutes les fonctionnalités,… ?

Tellement balayé que je ne l'ai pas encore vu! C'est réservé aux megas corpos comme Orange?

Même pas, chez Orange ils ont leur propre suite logiciel pour faire des visioconférences et autres choses similaires (Webinar, etc.). C'est de la techno web, et la seule fois que j'ai testé (il y a au moins deux ans), ça marchait nickel sous Linux :)

Mais il y a un monde de difference entre le boulot a faire avec Emacs/VIM et ce qu'un IDE decent offre de base.

C'est bien pour ça que RMS est passé à Java + Eclipse !

Allez, j'arrête le troll, car tu as raison dans 90% des cas je pense. C'est juste que je n'aime pas l'absolutisme qui dit « c'est bon pour la majorité alors c'est bon pour tout le monde ! ».

Encore une fois, tu généralise ta propre expérience. J'ai oublié de citer la machine à café, mea culpa.

Productifs avec Emacs/vim ?

Oui !
Allez, un exemple parmi d'autres, spécialement choisi pour alimenter le débat :)

Emacs/vim requierent de tout faire a la mano, ou se coltiner un travail de creation de l'environement (build system + debugger + editeur +…) soi-meme qui est une perte de temps inimaginable.

C'est vrai dans l'absolu, mais les IDE ne font pas tout non plus, et des fois ils font même perdre du temps (une demi journée de mise à jours, pour ré-importer un vieux projet dans Eclipse :( ). Je resterai sceptique la dessus.

J'ai vu « SM » dans le titre alors j'ai voulu le lire le journal (qui n'est pas inintéressant pour autant).

Bref, pour les incultes comme moi ITSM = « Gestion des services informatiques ».

Cette idée de navigateur p2p est en fait particulièrement intéressante pour obtenir un site supportant un pic d’affluence.

Les californiens le font depuis 2007 avec Flashback. Ils redirigent le trafic, de façon vraiment ingénieuse, vers les clients web eux mêmes. Ça à l'air assez similaire, mais je n'ai jamais vu personne l'utiliser :(

À mon avis, le gros point fort de SyncNet sera atteint lorsqu'il y aura un DNS décentralisé et intégré au protocole. Là on pourra parler de révolution.

Courage les gars !

Pour info, les lecteurs de Linuxfr ne sont pas tous des intégristes du libre, et savent aussi noter la pointe d'humour.

Raté ! Je n'avais pas compris qu'il s'agissait d'humour, je pensais plus à l'oubli d'un mot du genre : « ceux qui bossent en infogérance », ou autre. Bon, mea culpa si c'était de l'humour, je n'avais pas vu.

Sinon, c'est pas Lync que je visais, c'est le fait qu'on en ait besoin pour bosser. Il existe des multitudes de postes différents dans le monde de l'informatique (et là je passe au-dessus des considérations libre/non libre), et tous n'ont pas besoin de Lync. C'est tout ce que je disais.

Il y a encore des gens à notre époque qui sont très productifs en ne travaillant qu'avec Vim/Emacs, gcc, Mutt et XMPP :), ce qui ne veut pas dire que les autres outils ne sont pas intéressants : « à chacun ses besoins ».

Ceux qui bossent utilisent certainement Lync

Arf, c'est rude comme introduction, pour un journal sur linuxfr !

Tu vas rire, mais je bosse dans une préhisto-PME dans laquelle on utilise un outil d’antan : « le téléphone ». Et on arrive même à téléphoner aux Amériques et en Chines (progrès quand tu nous tiens !).

Pour les rares fois où j'ai besoin de messagerie instantanée au boulot, n'importe quel client XMPP fait très bien l'affaire !

J'oserais aussi celle-ci : http://www.youtube.com/watch?v=aAhyZp2j8F8

Sérieusement, quand je la regarde, outre le fait que je me marre toujours, je me dis que je me ferai vraiment chier avec une femme parfaitement soumise aux critères machistes.

On va arrêter un jour avec ça?

tandis qu'un code sous licence BSD est un peu plus libre : le code peut être utilisé sans être reversé à la communauté.

Oui dès que tous le monde aura compris les licences libres, c'est-à-dire, hummm…. jamais :)

J'essayais de reprendre les propos de Miguel pour comprendre cette histoire de « crédit », mais j'ai fait des non-sens. En parlant de communauté, je pensais qu'il faisait référence à l'ensemble des utilisateurs, mais je m'aperçois qu'effectivement c'est un terme ambigu (puisque défini nul part dans le texte des licences) et à proscrire.

Ce que je voulais exprimer, c'est l'intuition (peut être mauvaise) suivante :

• Si je publie mon code sous GPL, je ne m'attends pas à ce que d'autres personnes que des utilisateurs contribue.
• Si je publie mon code sous BSD (ou autre licence libre et non-copyleft) je peux m'attendre à ce qu'une boite reprenne mon code pour en faire ce qu'elle veut. Un peu à la manière de Google, qui ne s'intéressait à une époque qu'aux projets libres licenciés Apache, LGPL, MIT, BSD, mais pas GPL.

Je ne sais pas si cette intuition est bonne, mais en tous cas c'est comme ça que je comprend les choses pour le moment.

Ici, je n’émet aucun jugement de valeur. Je n'ai essayé que de retransmettre l'idée.

C'est plus avec la vue de la FSF (que tu retranscris plutôt bien dans ton propos) que je ne suis pas d'accord, pas avec ton commentaire :)

Maintenant, pour reprendre ton exemple, le "crédit" donné à un produit n'a aucune essence au regard de la GPL ou de la FSF. Ce qui a de la valeur c'est le code (dans le cas du logiciel) et donc ce qui est créditable ce sont les améliorations, les modifications au profit de la communauté. C'est peut-être ici aussi une différence avec ce qui est attendu avec une licence de type BSD.

J’essaie de suivre :

Grossièrement, un code GPL est en quelque sorte voué à être développé/maintenu par et pour une communauté d'utilisateurs, tandis qu'un code sous licence BSD est un peu plus libre : le code peut être utilisé sans être reversé à la communauté. C'est bien à cela que tu fais référence en parlant de crédit ?

La GPL considère la privatisation des efforts communs comme un mal à éviter.

Sans émettre de jugement, la formulation suivante serait plus juste : « La GPL considère la privatisation de toute amélioration apportée au produit des efforts communs, comme un mal à éviter ».

Car la phrase initiale s'applique aussi pour la BSD, selon la définition que l'on a de « efforts communs ». Si par exemple on considère les efforts de développement/maintenance du projet initial.

Elle est là pour éviter que quelqu'un (individu ou raison social) cache, rend privé, ses modifications et améliorations du projet communautaire

Je le comprend aussi comme ça.

à ses seuls fins et au détriment des utilisateurs et in fine de la communauté.

C'est là que je ne suis pas d'accord, car on peut imaginer, par exemple, un jeu non-libre utilisant un moteur graphique libre, qui amènerait indirectement du crédit au moteur graphique et plus largement au monde du logiciel libre. Ce qui ne tombe pas dans la case « au détriment des utilisateurs et in fine de la communauté ».

Les effets néfastes d'œuvres dérivées existent aussi, et la GPL protège contre ces effets néfastes. Mais cette protection est faite au détriment des effets potentiellement avantageux (comme l'exemple cité plus tôt). C'est un choix respectable, mais il faut avoir conscience que la GPL ne fait pas que protéger. Elle fait aussi une croix sur la publicité potentielle (entre autres effets bénéfiques) qu'une œuvre dérivées privée peut avoir.

Finalement, je suis d'accord pour dire que GPL et BSD ont chacune leur utilité selon le contexte voulu, mais attention à ne pas diaboliser trop vite les œuvres dérivées non-libres !

Vas dire ça aux alims de leurs serveurs :)

En soi-même, pas grand chose, mais ça sous-tend que Bitcoin a un effet bénéfique, puisqu'il est mentionné. Or ces dollars proviennent de quelquepart, ils ne sont pas tombés du ciel.

Il y a un vrai concept publicitaire : « Pour deux kilo de cocaïne achetés, un projet de logiciel libre sauvé ! ».

Une idée, farfelue mais pas si irréaliste que ça me traverse l'esprit : Les barons de la drogue et autres grands bandits (qui aiment, j'imagine avoir des réseaux sécurisés) n'utiliseraient-ils pas OpenBSD ?

Le roumain Mircea Popescu fondateur de mpex et détendeur d'un tel nombre de Bitcoin qu'il en serait milliardaire aurait intégralement payé les 20 000$ que demandait Openbsd pour couvrir ses frais de serveurs et autres.

S'il a payé en Bitcoin, OpenBSD n'est pas encore sortie d'affaire !
-->[]

Plus sérieusement, c'est une nouvelle réjouissante. Merci à lui !

C'est une très bonne idée :)

J’accepterai avec plaisir cette « feature », mais le Web avec ses ressources démesurées, nous habitue à disposer d'un archivage quasi total et absolu (du moins c'est le cas pour tweeter). Du coup je dirais que la problématique va se situer dans les compromis que les utilisateurs sont disposés à faire et se résume ainsi (à peu près) : « Est-ce que les utilisateurs sont prêts à faire une croix sur l'archivage supérieur à 15 jours (ou disons 30,60 jours même) pour bénéficier de la décentralisation, liberté, gratuité et de la démocratisation du service ? ».

La réponse n'est pas évidente, du moins à grande échelle.

Tu pourrais aussi le faire tomber par inadvertance, et il se trouverait qu'on le ramasserait, mais que ne retrouvant pas le propriétaire, on le lirait. Par pure curiosité scientifique.

J'aime cette idée ! Mais je préfère le donner par mail à ceux qui le veulent. D'ailleurs j'en ai plein d'autres…

Puisqu'il y a des courageux masochistes dans l'assistance, il y a la thèse d'Alessio Pace qui résume développe le papier en une quarantaine de pages. Plus sérieusement, si certains sont intéressés pour s'instruire sur les réseaux pair-à-pair non structurés, je conseille la thèse d'Alessio qui est très bien faite. Pour les non anglophones, vous pouvez lire la mienne aussi, mais c'est plus généraliste et le protocole en question n'y est pas décrit.

Le document est accessible si tu es dans une université qui a un accès à IEEE, ce qui est le cas d'à peu prêt toutes les universités, je pense que c'est pour ça tout le monde s'en fout que le document ne soit pas sur HAL.

Je ne suis pas tout à fait d'accord, tes arguments préalables sont valables. Maintenant que je ne travaille plus pour la recherche je n'ai plus accès à ces articles et je suis bien embêté. Si les prix des articles étaient raisonnables cela m'ennuierait moins, mais généralement c'est prohibitif pour un jeune hacker libriste :)

Alors , pour comprendre pourquoi les DHT ne sont pas très résilientes par nature : un article Usenix de référence.

Pour ce qui est du reste, les protocoles non structurés ont une résistance naturelles plus forte au churn (dynamisme du réseau lié aux départs/arrivées des pairs). J'ai déjà fait l'expérience (en simulateur) de faire tomber 60% du réseau sur un système utilisant des protocoles épidémiques pour maintenir la structure du réseau, et ça tient !

Pour approfondir les réseaux non structurés, tenant compte du NAT, il faut commencer par le papier « NAT-resilient Gossip Peer Sampling », malheureusement il n'est pas libre, comme beaucoup de papier de recherche. Je pourrais vous en faire un résumé au besoin.