Le monde du libre s'est appuyé pendant de longues années sur le serveur d'affichage X Window system. Le protocole X date de 1984 et, en dépit de nombreuses extensions, il commence à montrer son âge. De nombreuses critiques ont été émises sur le caractère impénétrable de son code, sur son modèle de sécurité inexistant et sur son inadaptation aux machines modernes.
Depuis 2008 un remplaçant répondant au nom de Wayland est développé par Kristian Høgsberg et de nombreux autres contributeurs. Ce nouveau protocole se débarasse de tout les résidus accumulés par X au fil des années et il propose une solution moderne et optimisée (voir cet article LWN qui explique les enjeux et cette vidéo de Daniel Stone à la conférence LCA 2013).
Il est important de noter que les développeurs de Wayland sont souvent d'anciens développeurs Xorg (Stone est un bon exemple) qui ont donc une connaissance poussée des limitations du serveur X et une expertise suffisante pour jauger les qualités de Wayland.
Après plusieurs années de développement, la première version stable 1.0 de Wayland est sortie en octobre dernier et le futur des distributions Linux semblait alors tout tracé. Après une phase de transition plus ou moins longue (le temps d'adapter les toolkits à Wayland) nous allions tous basculer vers ce nouveau protocole moderne et efficace.
Bien entendu, comme pour de nombreuses autres briques du système, les machines sous Android utilisent une solution d'affichage spécifique (nommée SurfaceFlinger). On peut penser que Google a voulu un système optimisé pour les smartphones et sur lequel il pouvait avoir la main sans être obligé de collaborer avec la communauté.
La situation future de l'affichage dans le monde Linux semblait donc claire : SurfaceFlinger pour les machines sous Android et Wayland pour les systèmes GNU/Linux traditionnels.
C'est pour ça que l'annonce de Canonical du développement de Mir, un tout nouveau remplaçant pour Xorg, a surpris et irrité de nombreux observateurs.
Canonical désire faire converger ses projets afin d'avoir une pile unifiée pour les machines de bureau et les smartphones. Selon cette société, Xorg et Wayland ne sont pas adaptés à cette convergence et il était necessaire de créer un nouveau protocole.
Aux yeux des développeurs de Wayland cette justification semble grotesque. Une discussion a immédiatement commencé sur le compte Google+ de Kristian Høgsberg et les critiques pleuvent.
Selon Daniel Stone la justification avancée est complètement fausse (et l'auteur du texte employé par Canonical n'a même pas pris la peine de se renseigner auprès des développeurs Wayland) :
The best part is that the input bit of the rationale is totally wrong: there's no way for clients to get another client's input, short of mapping a full-screen transparent window and convincing the compositor to not decorate it. There also aren't any grabs. Which I could've told them if anyone involved ever bothered to talk to anyone upstream.
Kristian Høgsberg a également souligné l'absurdité des arguments :
the things they claim wayland/weston input can't be extended to support (…) is already implemented and working in weston today…
Carsten Haitzler (le Rasterman du projet Enlightenment) est également très critique :
A reads of the mir stuff says to me "oh look. we don't understand wayland at all, neither do we grok X11 that much either". Their reasoning on the input in wayland are just total bunk. I would just say "ignore mir/canonical and just keep plodding on with wayland".
Dave Airlie (développeur noyau pour les pilotes graphiques) souligne l'amateurisme que révèle ce projet :
they barely have anyone competent enough to write a display server, the fact that they are actually quite ignorant of how wayland works makes it even more apparent.
Dave a également posté sur son blog au sujet du projet Mir :
Now the question becomes do you want the display server that you are going to base the future of the Linux desktop and possible mobile spaces on a server written by people too stupid to understand the current open source project in the space? The thing is putting stuff on the screen really isn't the hard part of display servers, getting input to where it needs to go is, and making it secure. Input methods are hard, input is hard, guess what they haven't even contemplated implementing yet?
Cette volée générale de bois vert s'explique par plusieurs facteurs. Tout d'abord le fait que ce projet Mir soit en cours depuis plusieurs mois (comme le révèle l'analyse de l'arbre Bazaar) ne présage rien de bon quand au degré d'ouverture de Canonical. Pourquoi avoir ainsi travaillé en secret ?
De plus, comme c'est souvent le cas avec Canonical, toutes les contributions extérieures devront passer par un partage du copyright (Contributor License Agreement). Cela signifie que Canonical aura le droit de changer la licence de vos patchs et d'inclure votre code dans un produit propriétaire.
Enfin le projet Mir est vu comme un risque de fragmentation inutile du monde du libre. Alors que Wayland semblait être la solution consensuelle sur laquelle tout le monde allait se rallier, l'apparition d'un projet concurrent, s'appuyant sur des justifications techniques douteuses et étant financé par une seule société, ne peut que diviser les forces.
Nous verrons dans les prochains mois si le projet de Mark Shuttleworth se révèle être une bonne idée. Dans l'intervalle on peut sortir le pop corn et regarder les trolls se déchainer !
# Owned
Posté par patrick_g (site web personnel) . Évalué à 8.
Ah zut j'ai mis trop longtemps à écrire et je me suis fait doubler par gnumdk ;-)
Désolé pour le bruit.
[^] # Re: Owned
Posté par Renault (site web personnel) . Évalué à 10.
Ce n'est pas du bruit, sans manquer de respect à l'auteur précédent (contribuer est toujours une bonne chose), ton article est plus constructif et approfondi ce qui apporte des éléments intéressants.
Tu aurais fait un journal bookmark sur le sujet, là ça aurait été du bruit.
[^] # Re: Owned
Posté par gnumdk (site web personnel) . Évalué à 10.
Je confirme, tu fais chier patrick_g, t'aurais pu le poster plus tôt quand même :)
# Lennart Poettering
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 05 mars 2013 à 11:08.
Au sujet des trolls qui vont se déchainer, je dois avouer que le commentaire de Lennart m'a fait beaucoup rire :
[^] # Re: Lennart Poettering
Posté par davandg . Évalué à 8.
Et il continue avec :
[^] # Re: Lennart Poettering
Posté par Sufflope (site web personnel) . Évalué à 3.
Au moins on peut espérer que les distribs' qui on été faites cocu par Canonical avec ces technos (Suse, RH… baisés, comptez-vous) ont compris et ne se poseront même pas la question Mir.
# Quelques précisions
Posté par davandg . Évalué à 9.
Il n'est pas si sure que cela que Mark Shuttleworth approuve à 100% ce projet, c'est Tom Arnold qui le fait remarqué dans la discussion Google+ citée dans l'article:
Phronix a tenté de voir l'état d'avancement de Mir. Pour l'instant Mir nécessite Xorg pour tourner et ne fait quasiment rien. Alors que Canonical reproche à Wayland/Weston de ne pas encore fonctionner correctement.
Canonical annonce que Mir rentrera en production début d'année prochaine. Wayland/Weston est en développement depuis plus d'un an et ils sont encore loin d'avoir fini.
[^] # Re: Quelques précisions
Posté par patrick_g (site web personnel) . Évalué à 8.
Bien plus que ça puisque le projet a débuté en 2008 et a atteint la version stable 1.0 en octobre 2012.
# Paragraphes
Posté par Anonyme . Évalué à -9.
Pour écrire un nouveau paragraphe, c'est deux sauts de lignes dans le champ d'édition. Un seul saut de ligne est affiché comme un saut de ligne à la lecture et celle-ci devient ultra chiante.
# Un détail qui a son importance
Posté par rahan . Évalué à 3.
Le nom du projet : Mir (Мир en russe). Cela signifie "Paix". Avaient-ils anticipé les réactions positives à leur annonce ?
# Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par dinomasque . Évalué à 10.
Il s'appelera Mir Express.
/o\
BeOS le faisait il y a 20 ans !
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
J'ai plutôt l'impression que pour éviter toutes ces critiques, il faudrait que l'on cache Mir.
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Adrien . Évalué à 7.
à trop se cacher, attention à ne pas devenir un Mir age…
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par BAud (site web personnel) . Évalué à 4.
ou Mir obolant
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Ignatz Ledebur . Évalué à 0.
j'aurais dit un Rafale, plutôt…
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Mali (site web personnel) . Évalué à 2.
lapin' compris…
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Ignatz Ledebur . Évalué à 4. Dernière modification le 05 mars 2013 à 15:59.
Aux dernières nouvelles, contrairement au Mirage, personne n'en veut… bon, encore une blague qui vaut même pas un Zéro. :)
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par ParaDoxe . Évalué à 8.
Si ce fork est fait par les inventeurs du transistors, ce sera la Mir à Bell.
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
En tout état de cause espérons que les développeurs de chez Canonical sauront nous en mettre plein les mirettes avec des performances mirobolantes. Mais soyons raisonnable : cela tiendrait du miracle. Même leur grand émir M. Shuttleworth ayant l'air de ne pas trouver ce développement stratégiquement admirable (cf. la citation dans l'article). En attendant, amis, râlons.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par fearan . Évalué à 3.
mouais en mais bon faut pas attendre de Mir acle.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par windu.2b . Évalué à 9.
Le prochain qui fait un jeu de mot pourri, je le préviens de suite : je l'aurai en ligne de mire !
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Mme Michu-cide . Évalué à 2.
Ils doivent être mirauds chez Canonical pour s'attaquer à un tel projet!
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Yukito (site web personnel) . Évalué à 6.
Laisse tomber, ce sont juste des mirliflores.
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par BAud (site web personnel) . Évalué à 3.
il est mirifique celui-là !
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par ZeroHeure . Évalué à 3.
"Moi j'n'ai qu'un mirliton
Et j'mirlitonne du soir au matin
Moi j'n'ai qu'un mirliton
Mais ça m'est égal si j'en joue bien
Oui mais voilà:
est-ce que j'en joue bien?"
Boris Vian
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 05 mars 2013 à 20:37.
Je ne connais pas ce JP mais là il avait un peu picolé là pour sortir ça, non ?
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par saltimbanque (site web personnel) . Évalué à 6.
Il planait complètement
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par El Titi . Évalué à 2.
Mir onton
Mir ontaine ….
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par reynum (site web personnel) . Évalué à 5.
Restons Pacifique, car c'est là qu'a finie la station Mir !
kentoc'h mervel eget bezan saotred
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par Meku (site web personnel) . Évalué à 2.
MIR IL ET FOU !
Bon ok c'est nul.
[^] # Re: Déjà un fork en vue pour avoir un code plus rapide et plus propre
Posté par El Titi . Évalué à 8.
Oui ce fork sera pas Mir mais quasi
# Discussion entre un dev MIR et les dev Wayland
Posté par gnumdk (site web personnel) . Évalué à 5.
http://pastebin.com/KjRm3be1
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Albert_ . Évalué à 4.
J'ai un peu l'impression que le probleme majeur c'est que wayland c'est du RH et que historiquement parlant Canonical s'est toujours fait rejeter toute ses propositions de changement et que en plus RH commence a avoir la sale habitude de forcer ses propres technos sans aucune concertation, PA, systemd pour ne pas les nommer, et sans bosser avec les autres distribs AVANT leur inclusion quasi definitive. D'ou le merdier PA ou il a fallu plusieurs annees avant d'avoir un truc qui fonctionne correctement en dehors d'une distrib base sur RH ou aujourd'hui avec l'inclusion de udev dans systemd sans tenir compte de toutes les autres distributions qui ne sont pas passe a ce truc.
Maintenant, j'aime pas du tout les dernieres decisions de Canonical qui navigue visiblement a vue, le fait d'abandonner unity-2d et maintenant y revenir, le fait d'obliger le transfert de copyright (ca je suis persuade que c'est une des pire decisions et que enormement de devs refusent de participer a cause de cela), le developpement non officiel voir ferme des nouvelles idees et technos (en meme temps c'est pareil chez RH pour pas mal de chose en particulier ceux du roi du troll).
Bon il va falloir que je prenne le temps de me mettre a arch si je veux avoir un KDE recent sans tout un tas de merde…
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par gnumdk (site web personnel) . Évalué à 6. Dernière modification le 05 mars 2013 à 15:47.
Moi ce que je comprend surtout, c'est que la doc de Wayland n'est pas à jour et que les devs de Canonical se sont basés sur cette dernière dans leur refus de Wayland…
Après, certes, ils auraient pu quand même avoir cette discussion avant de commencer à coder nez dans le guidon.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par akimatsumoto . Évalué à 4.
Pas sur que passer à Arch empeche les "merdes", ils ont déja systemd à la place de init, et je ne pense pas qu'ils aient la force de frappe suffisante pour ne pas suivre les grandes tendances du mode linux. D'ailleur je viens de voir que wayland vient d'etre installer sur ma Arch, donc apparament le basculement de serveur graphique est déjà dans les tuyaux (Même si Xorg est encore la pour qq temps).
Je précise que je n'ai aucun avis sur le faite que PA, systemd et consort soit des "me#de" ou pas, ma connaissance des entrailles des programmes est bien trop mauvaise, c'est juste le constat que les petites distrib ont rarement la possibilité de faire des choix techniques très important au niveaux des briques fondamentales, donc je ne m'attendrais pas à des miracles de la part de arch
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Misc (site web personnel) . Évalué à 10.
Wayland, c'est surtout du intel.
Et non, je pense que Canonical se soit fait toujours rejeter. Par exemple, il y a une personne payé par Canonical sur pulseaudio maintenant. Il y a pas de soucis sur network manager, et fedora/RHEL ont adopté upstart pendant un temps, RH a intégré openstack, projet fortement influencé par Canonical.
L'idée que les gens fassent des choix pour des raisons techniques et ne soit pas d'accord, en dehors d'un quelconque corporatisme semble vraiment être une idée passé. je sais qu'un monde avec 2 groupes en opposition est plus rassurant car plus facile à comprendre qu'un monde ou des humains ne sont pas d'accord pour des raisons trop techniques pour toi, mais ça ne veut pas dire que c'est la réalité.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par glisse . Évalué à 8.
C'est un bien jolie troll que tu as là :)
D'abord systemd et pulseaudio ont été réalisé ouvertement avec la participation de nombreuses personne extérieur à Red Hat. Je vais pas revenir sur l'historique des deux projets mais tu es libre de vérifier par toi même que les contributeurs de la première heure ne se réduisent pas à des employés de Red Hat. Pour t'aider :
http://cgit.freedesktop.org/systemd/systemd/log/?ofs=2300
http://cgit.freedesktop.org/systemd/systemd/commit/?id=79849bf9f47f9867c72c7eb76b981bb354d0e30e
http://cgit.freedesktop.org/pulseaudio/pulseaudio/log/?ofs=6500
Donc merci de ne pas continuer à rependre des contre vérités. Non Red Hat ne force rien sur personne.
Note que je travaille pour Red Hat et ce qui compte ici c'est l'excellence technique si une autre compagnie propose une meilleure solution technique c'est ce que l'on utilisera.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par fravashyo . Évalué à 4.
Canonical non plus d'ailleurs.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Sufflope (site web personnel) . Évalué à 5.
glisse répondait à RH commence a avoir la sale habitude de forcer ses propres technos sans aucune concertation, personne n'a dit que Canonical le faisait.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par El Titi . Évalué à 3.
Donc merci de ne pas continuer à rep**en**dre des contre vérités.
On ne l'y repr**an**dra plus.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par moi1392 . Évalué à 1.
Il fut un temps ou la suite rpm était bien à la ramasse techniquement par rapport à deb. Que cela soit pour le format ou pour les outils qui vont avec.
Je n'ai pas vraiment eu l'impression que RH était près (ni même loin) d'adopter ce système de packaging.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Anonyme . Évalué à 1.
Ca depend ce que tu veux dire par "etre à la ramasse techniquement". Si pour ne pas etre à la ramasse techniquement il faut avoir des tas de fichiers de config dans des formats differents, des tas d'options et de cas speciaux partout, des tas d'outils differents pour faire plus ou moins la meme chose, alors effectivement on peut dire que le packaging debian est très très avancé techniquement.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . Évalué à 10.
La même rengaine, sans la moindre argumentation. En quoi le format RPM était-il inférieur au format dpkg ? [1] dpkg n'a supporté le multiarch que depuis l'année dernière, RPM le fait depuis des années. Tant que dpkg ne gérait pas le multiarch, aucune chance que RH ou SUSE n'envisagent même de l'adopter et ça sans prendre en compte le coût du changement de toute l'infrastructure associée.
La plupart des problèmes attribués à RPM sont dû au fait que pendant longtemps, les utilisateurs ont mélangés différents dépôts incompatibles entre eux (voire pas très catholiques pour certains) ou installer des RPM destinés à d'autres distros [2]. En revanche, Debian a préféré centralisé la maintenance des paquets chez eux, et ils ont eu raison de le faire. Devine quoi, avec l'apparition d'Ubuntu et des PPA, les utilisateurs d'Ubuntu connaissent également les mêmes problèmes que les utilisateurs de Mandrake/Mandriva, RHL ou bien SuSE il y a 10 ans avec la multiplication des dépôts incompatibles entre eux.
Idem les gens confondent également dpkg avec les outils de plus haut niveau (apt/aptitude), certes leurs homologues du monde RPM d'il y a 10 ans n'étaient pas à la hauteur mais aujourd'hui: yum/zypper/urpmi sont tout aussi bons, voire meilleurs sur certains aspects (essayez de faire un rollback d'une transaction avec apt).
[1] un vieux billet d'un de mes confrères packager fedora qui avait lancé une discussion constructive. Certes la situation a évolué entre-temps, mais c'était pas aussi tranché qu'on le prétends à l'époque
[2] les distros RPM ont longtemps très mal géré ce problèmes, dans le cas de Fedora, on a fini par centraliser (soit au sein du projet, soit à travers de RPMFusion pour les paquets non acceptables par le projet) la gestion des paquets pour régler de manière satisfaisante ce problème.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . Évalué à 9. Dernière modification le 05 mars 2013 à 21:32.
Pas un problème, Wayland n'a jamais été un projet RH y compris lorsque Kristian bossait chez RH (il est actuellement chez Intel)
T'as des preuves de ce que t'avances ? c'est bizarre que des tas d'autres boites y compris concurrentes de RH n'ont aucun soucis à collaborer pour GNOME.
En revanche, Canonical adore lancer des projets dans son coin et balancer des patchs mal branlés sans vraiment dialoguer avec upstream pour les intégrer proprement. Le problème, il se situe au niveau du management de Canonical plutôt qui ne laisse aucune place à la collaboration upstream.
Foutaises, PA a été développé pendant des années pour être le remplaçant d'esound avant intégration. La seule distro qui a foiré son intégration de PA est la seule à l'avoir fait sans concertation avec upstream (qui lui aurait conseillé d'attendre une release non-LTS et aidé à corriger des problèmes évidents de packaging), je te laisse deviner laquelle …
Quant à systemd, il a été développé dès le premier jour avec des développeurs d'autres distros (le co-leader Kay Sievers bossait à l'époque chez SUSE).
Non, libre à eux de maintenir udev tel quel, d'ailleurs c'est ce qu'ils ont fait.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par BAud (site web personnel) . Évalué à 2.
hmmm pourrais-tu élaborer ? Par exemple, pour les bugs, il est possible de référencer les bugs dans les autres distros voire upstream ce qui permet d'avoir des bugs référencés en commun : par exemple, https://bugs.launchpad.net/ubuntu/+source/scim-bridge/+bug/243344 (debian, fedora…). Après, c'est possible, je ne sais pas si c'est systématiquement fait, il est vrai.
Quelqu'un connaissant mieux ubuntu que moi pourra sans doute trouver le même genre de références inter-distro pour les paquets ? (au moins vers debian j'imagine, comme pour http://packages.ubuntu.com/quantal/evolution qui utilise le même logiciel que chez debian http://packages.debian.org/stable/math/carmetal).
Note : je me suis permis d'éditer ton commentaire pour rajouter une ligne blanche pour mieux faire apparaître les citations, comme cela est indiqué dans l'aide Markdown.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Misc (site web personnel) . Évalué à 2.
De ce que j'ai vu, c'est plus que le temps n'est pas toujours laissé. Ça dépend grandement des équipes, mais il y a une pression assez grande pour remplir les objectifs des blueprints en temps et en heure, ce qui laisse peu de temps pour la discussion et le long terme.
Quand on regarde divers controverses ( exemple, python dans debian à l'époque ), on voit qu'il s'agit surtout de gens qui n'ont pas le temps, qu'ils veulent des résultats rapides.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . Évalué à 2.
Je pense que misc a parfaitement expliqué ce point-ci. Malgré les outils, malgré la bonne volonté, il reste encore la question épineuse du management (comme quoi, les p'tits chefs hexagonaux n'ont pas le monopole de la vision courte)
PS: merci pour l'édition !
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Jean-François A. . Évalué à 10.
Wayland c'est du Intel, Collabora, Red Hat et autres. Mais surtout, c'est la solution que la communauté X.org avait décidé d'entreprendre collectivement comme remplacement, contrairement à Mir qui n'est qu'un jeu politique et une tentative de prise en otage des technologies les plus fondamentales de notre écosystème.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par fravashyo . Évalué à -4.
un peu comme systemd quoi ?
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . Évalué à 3.
au lieu de raconter n'importe quoi, va jeter un coup d'oeil sur les listes et les logs des dépôts git …
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par totof2000 . Évalué à -5.
N'empêche que systemd sapukanmem.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par xcomcmdr . Évalué à 3.
Une prise en otage… sous licence libre ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Kekun (site web personnel, Mastodon) . Évalué à 3.
Certes, mais la licence ne fait pas nécessairement l'écosystème.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par Jean-François A. . Évalué à 2.
Parmi tant d'autres choses, jette un oeil à la section 2.3 ("Outbound license") de leur CLA (Contributor License Agreement). Dernière version: http://www.canonical.com/sites/default/files/active/images/Canonical-HA-CLA-ANY-I.pdf
C'est pas pour rien que personne d'autre que Canonical ne veut/peut contribuer aux projets de Canonical: c'est leur donner une license "perpétuelle, mondiale, non-exclusive, transférable, royalty-free, irrévocable" pour rendre notre code propriétaire dès qu'ils en sentent le besoin.
# Quelques infos
Posté par reno . Évalué à 6.
1) J'ignore pourquoi Wayland et SurfaceFlinger existent tout les deux au lieu d'avoir un seul projet (on pourrait se poser aussi la question avec DirectFB!!) mais un dev Wayland a fait tourné un proto (proof of concept) de Wayland sur Android:
http://ppaalanen.blogspot.fi/2012/07/wayland-on-android-snapshot-release.html?m=1
2) Le truc qui a agacé les dev Wayland, c'est que le wiki de Mir dit que Wayland a le même problème de sécurité qu'X alors que c'est faux (les évènements ne sont envoyés qu'à un seul client et un client Wayland ne peut pas envoyer d’évènements), ça a été corrigé dans le Wiki de Mir: https://wiki.ubuntu.com/MirSpec?action=diff&rev2=4&rev1=3 ce qui devrait apaiser la situation.
[^] # Re: Quelques infos
Posté par cedric . Évalué à 10.
Principalement parce que SurfaceFlinger est un projet a code ouvert que Google controle completement et destine uniquement a l'embarque (Google ne l'utilise pas sur ses ChromeBook). Wayland a l'oppose a ete concu pour pouvoir fonctionner sur toute la gamme des machines sur lequel un Linux tourne. Le protocol est le resultat de la cooperation de personne qui ont des annees d'experience avec X, les Window Manager, les Composite Manager, les drivers, les toolkits graphiques, en securite, en embarque … C'est un travail enorme et colossale qui a ete realise et il y a encore beaucoup a faire. La plus part des gens ne se rendent pas compte de l'ensemble des contraintes et des problemes a resoudre. La plus grande reussite de Wayland, c'est d'avoir reussi a attirer tous ces gens. Ce que ni SurfaceFlinger, ni DirectFB et pas non plus Mir a reussi a faire.
Quand on regarde la TODO de Mir, on se rend compte qu'ils n'ont meme pas encore attaque les sujets difficiles. Il y a un total manque d'experience de leur cote et ce projet va probablement avoir un destin funeste.
Il est comprehensible qu'ils se demarque de X, vu qu'ils ont du mal a monetiser leur plateforme Linux desktop et qu'il se tourne vers Android pour ca. Or cela veut dire se baser alors sur la stack graphique de Android. Je comprend en tout cas leur effort vers Mir comme un objectif de devenir une distribution Android. Mais bon, ils ont loupe que le protocol Wayland ne definit pas ce qu'est un buffer ID et que sous Android on aurait tres bien pu utiliser Gralloc. Il n'y a rien d'ailleur qui empeche d'ajouter un second protocol a son serveur Wayland pour gerer le protocol de SurfaceFlinger quand on est sous Android.
Il est tres probable que la plus part des implementations de Wayland implemente a terme plus que juste KMS. Ainsi avoir un backend fbcon est necessaire pour etre portable sur les BSD. Un backend XPixmap pour avoir acces au driver proprio NVidia. Donc un backend Android ne sera finalement plus que un backend supplementaire. Pourquoi pas aussi un backend SDL ? Et le code necessaire pour ses backend se limitera a peu de chose pres a gestion de buffer et lecture des inputs. Tout le reste du code etant commun a toutes les plateformes.
[^] # Re: Quelques infos
Posté par nud . Évalué à -1.
Si le but est d'être interopérable avec Android comme tu le mentionne, alors faire un nouveau display server n'est pas très intelligent, cela fait encore un protocole en plus à supporter. Idem sous Linux. Quand on voit la difficulté pour avoir ne fut-ce que le support de Wayland dans les toolkits et applications majeurs sous linux, ils vont s'amuser pour ajouter le support de mir partout.
Sans oublier le XKCD de rigueur:
[^] # Re: Quelques infos
Posté par reno . Évalué à 10.
Je trouve que le dessinateur d'XKCD aurait du mettre le nombre de standard en dynamique: a chaque fois que quelqu'un lie cette image il est incrémenté.. Ca fait tellement de fois que je la voie cette image, ça devient pénible..
[^] # Re: Quelques infos
Posté par Alex . Évalué à 5.
En même temps, la situation évoquée se retrouve souvent…
# Google +
Posté par O'neam Anne . Évalué à 5.
Est-ce que c'est moi, ou est-ce que Google+ est plus populaire auprès des développeurs (ou des rédacteurs LinuxFRiens) que Facebook ou autre ? Il me semble qu'on a régulièrement des liens vers des remarques de Linus Torvalds, Lennart Poettering ou ici Kristian Høgsberg sur Google+, alors qu'il ne me semble pas avoir jamais vu de liens équivalents vers des discussions Facebook ou autre « réseaux sociaux » entre développeurs sur LinuxFR.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Google +
Posté par reno . Évalué à 8.
Ce n'est pas toi..
[^] # Re: Google +
Posté par Yukito (site web personnel) . Évalué à 6.
Google me semble effectivement relativement toléré par les développeurs, probablement parce que Google est dans l'ensemble très amical vis-à-vis du libre. Google a contribué énormément de code, et soutient aussi financièrement des projets, comme par exemple la fondation Mozilla. En comparaison, Facebook ou Twitter n'ont quasiment rien apporté aux logiciels libres.
Par contre, à titre personnel, je ne participe ni à Google+ ni à Facebook. Je trouve que c'est bonnet blanc et blanc bonnet.
[^] # Re: Google +
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
A l'utilisation, je trouve G+ beaucoup plus épurée et simple que Facebook, le flux, rien que le flux.
Une sorte de "super-twitter".
[^] # Re: Google +
Posté par reno . Évalué à 3.
Et personnellement je trouve ça les 2 très chiant à lire, dès qu'il y a un peu de message: pas d'arborescence == le bazar.
Ces 2 "médias" n'ont pas vraiment aucun intérêts pour des discussions sérieuses..
[^] # Re: Google +
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Ah oui, je suis absolument d'accord là dessus, c'est plus pour de la diffusion "one shot" d'infos, le système de commentaire ne permet pas d'approfondir sereinement une discussion.
[^] # Re: Google +
Posté par claudex . Évalué à 7.
Une grosse différence de Google+ par rapport à Facebook (à moins que ça ait changé), c'est qu'il possible de publier de manière publique sur G+, alors que sur Facebook, il faut créer une page dédié à ça.
Facebook a beaucoup sur Hadoop, a créé Hip Hop, ont un projet de design ouvert de leur server et d'autres chose. Twitter a bossé du côté de (J)Ruby je crois, et bootstrap est assez utilisé.
« 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: Google +
Posté par zebra3 . Évalué à 3.
Alors que Google a juste développé deux OS basés sur Linux et un navigateur.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Google +
Posté par Sufflope (site web personnel) . Évalué à 0.
Ah oui, un machin en Java (moi ça me gêne pas, mais je m'adapte au lectorat) qui rame, et un qui sert juste de client web à leur cloud et leurs pubs. Supaÿr.
Une GUI pour Webkit, tu veux dire.
C'est pas pour taper sur Google, c'est juste que dire « eux ils font plein de libre alors que FB et T ne contribuent rien » c'est une grosse connerie.
[^] # Re: Google +
Posté par claudex . Évalué à 5.
Et Webkit ne se développe pas tout seul, Google est le deuxième contributeur (et vu comme c'est serré, on peut dire que c'est le premier à égalité).
« 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: Google +
Posté par Sufflope (site web personnel) . Évalué à 2.
À égalité avec Apple, donc Apple c'est le bien, comme Google ?
[^] # Re: Google +
Posté par Albert_ . Évalué à -4.
Bof Apple il a fallu qu'ils se prennent un coup de pied dans les c…. pour respecter la licence de khtml donc non c'est pas pareil.
[^] # Re: Google +
Posté par Troy McClure (site web personnel) . Évalué à 6.
ça serait pas un peu des gros mensonges que tu nous écris, là ? http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2
[^] # Re: Google +
Posté par GG (site web personnel) . Évalué à 1.
Il me semblait que les modifications apportées par Apple au code de KHTML étaient fournies d'un coups, sans les multiples étapes, et étaient donc totalement inutilisables.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Google +
Posté par Zenitram (site web personnel) . Évalué à -4.
Et?
Pour rappel, le libre n'interdit pas de fournir tout d'un coup, le libre n'oblige pas à avoir un truc "totalement utilisable" (tu définis ça comment d'ailleurs?), le libre n'impose même pas de remonter upstream, donc ce que tu racontes n'a absolument rien à voir avec le sujet (le respect de la licence).
[^] # Re: Google +
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Attention, Zenitram a décidé qu'on ne parlait plus que de respect de la licence maintenant.
C'est bloqué, désolé, pas possible de parler d'utilisabilité d'un patch ou d'autres sujets annexes.
Allez oust !
[^] # Re: Google +
Posté par Prosper . Évalué à 6.
Relis le fil, c'est quand même un peu Albert_< qui a parlé uniquement de respect de licence hein …
[^] # Re: Google +
Posté par zebra3 . Évalué à 7.
Je ne sais pas si c'est encore le cas actuellement, mais c'est exactement ce qu'a fait Red Hat pour ses patch noyau lors de la sortie de RHEL6 et ça a bien ennuyé les devs de CentOS.
Doit-on en déduire que Red Hat, c'est le mal ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Google +
Posté par rewind (Mastodon) . Évalué à 3.
Oui. En plus ce sont tous de vils capitalistes, mangeurs d'enfants et de chatons. C'est dire à quel point c'est le Mal !
[^] # Re: Google +
Posté par Misc (site web personnel) . Évalué à 4.
Non, les devs de Centos n'ont pas vraiment été ennuyés.
http://www.channelregister.co.uk/2011/03/04/red_hat_twarts_oracle_and_novell_with_change_to_source_code_packaging/
Oracle et Suse, peut être plus, vu que c'était le but visiblement.
Certains devs Debian ont aussi pas aimé le coup, de ce que j'avais lu un jour.
[^] # Re: Google +
Posté par Anonyme . Évalué à 3.
« Allez, Salut ! et merci pour tout le poisson »
[^] # Re: Google +
Posté par totof2000 . Évalué à 1.
"Comment ça, il est pas frais mon poisson ? "
PAFFFF !!!
[^] # Re: Google +
Posté par barmic . Évalué à 7.
Je pense que l'investissement est nettement plus colossale du coté de google (Google Summer of Code, Chrome/Webkit, Android, Linux, VP8 (WebM et WebP), Wine,…), un tas de machins pour développeurs (Go, Guava, Guice, des outils moins répandus lié au développement de crhome comme ninja,…) et de manière moins libre avec les développeurs (Google Code entre autres).
Twitter et Facebook non seulement contribuent moins, mais ils contribuent à des projets qui ont moins de publicité (ils ne servent pas à tout le monde (en tout cas directement)), à mon avis ça explique le déficit d'image de Twitter et Facebook sur Google.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Google +
Posté par groumly . Évalué à 5.
Chez les devs linux et employes google, nuance.
A se demander meme si c'est pas le principal usage de g+ - en tout cas c'est le seul que je vois moi, de mon petit bout de lorgnette.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Google +
Posté par fearan . Évalué à 2.
ben à la base un truc qui n'impose pas vraiment de donner son vrai nom (ou du moins qui ne supprime pas le compte), qui est intégré avec les téléphones intelligent (pour le coup, ils ont encore mieux que le vrai nom), qui au moment de sa sortie, avait corrigé certains défaut de fb, moins pollué par les kikoo lol qui t'invitent à tour de bras…
Bref ça touche un autre publique. Et personnellement donner mon vrai nom sur FB ou g+, c'est hors de question. Quiconque me connais un tant soit peu peut connais mes pseudos généralement utilisés, mais ça reste de la sphère non professionnelle, et je pense que dans l'informatique la culture du pseudo est plus répandue qu'ailleurs.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Google +
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
Ton réseau de connaissances en dit bien plus sur toi que ton vrai nom.
[^] # Re: Google +
Posté par fearan . Évalué à 4.
la grosse différence c'est que tu ne peux pas tomber sur mon réseau de connaissance en tapant mon vrai nom. (J'ai essayé) Alors qu'avec FB, c'est foutu.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Google +
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Oui, c'est vrai, l'objectif de l'anonymat est probablement plus envers les autres qu'envers google lui-même, j'imagine.
[^] # Re: Google +
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Et qui ne nécessite pas de s'inscrire pour lire ce que les gens y écrivent. Je pense que ça joue aussi, ça.
[^] # Re: Google +
Posté par groumly . Évalué à -1.
Parce que bien sur, Google+ ne permet pas de faire de post prive, et Facebook met tout en prive par defaut, c'est meme la principale complainte a propos de FB, ils sont tres soucieux de la vie privée et les gens voudraient plus d'ouverture de leur part.
Ca t'arrive de te renseigner sur les services que tu critiques, des fois?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Confusion
Posté par lolop (site web personnel) . Évalué à 2.
X (X11 actuellement) ce n'est pas un code, c'est un protocole (comme indiqué dans l'article d'ailleurs). Donc, que certains serveurs X aient des sources compliqués, c'est un autre problème que celui de l'adaptation du protocole au monde actuel.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Confusion
Posté par Yukito (site web personnel) . Évalué à 4.
Oui, mais bon, des implémentations, il y en a pas des milliers, hein. Il n'y a en gros que Xfree86 dont le développement est abandonné depuis plusieurs années, et le fork X.org.
[^] # Re: Confusion
Posté par lolop (site web personnel) . Évalué à 4.
Et des softs commerciaux fermés.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Confusion
Posté par karteum59 . Évalué à 2. Dernière modification le 06 mars 2013 à 11:57.
Il y a aussi android-xserver
(et aussi apparemment d'autres implémentations comme weirdx
# Nique les zoulous
Posté par calandoa . Évalué à -10. Dernière modification le 05 mars 2013 à 16:43.
À noter que la FSF songe à ajouter une liberté numéro 4 suivante à la définition du logiciel libre:
- si vous n'utiliser pas les libertés susmentionnées et que vous recommencez un nouveau projet à zéro, vous êtes libre de vous faire traiter de gros batard, d'enculé de votre race, de fils de pute, de chien galeux, bien entendu de nazi, et d'autres sobriquets affectifs par le reste de la communauté, en particulier si vous avez un lien avec une entreprise ayant pour nom un mot zoulou.
[^] # Re: Nique les zoulous
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Conformément aux règles de modération du site, merci d'éviter d'utiliser un langage grossier/vulgaire
# Les dévs Wayland devraient être contents...
Posté par Maclag . Évalué à 10.
Quand on lit tout ce qu'ils balancent sur les devs de Canonical, qu'ils ne bitent rien à Xorg, qu'ils ne bitent rien à Wayland, qu'ils ne bitent rien au système où les "input", c'est LE truc chaud, on se dit qu'on est plutôt rassurés de savoir que cette bande de manches ne viendra pas saboter Weston!
Hop, moi! ----> [ ]
[^] # Re: Les dévs Wayland devraient être contents...
Posté par reno . Évalué à 2.
Ce n'est pas totalement faux, m'enfin je pense que l'impression que les devs de Canonical ne comprennent rien sont due au wiki, sauf qu'à mon avis le wiki il a été fait par le stagiaire qu'on cherchait a occuper plutôt que par les devs.
La preuve quand un dev de Mir dialogue avec les devs de Wayland sur IRC ( http://pastebin.com/KjRm3be1 ), on peut "résumer" la conversation comme ça:
W-Gérard, tu fais ce que tu veux mais arrête de dire que Wayland a le même problème de sécurité qu'X!
M-Hein? mais non on n'a jamais dit ça..
W-Si, ici!
M-Et m… --> le wiki est modifié
Ceci dit quand on voit que ça ne dérange pas grand monde qu'il y ait 2 systèmes de packaging totalement équivalent (.deb et .rpm, NixOS est différent), je ne vois pas trop pourquoi on tapes sur Canonical pour Mir..
[^] # Re: Les dévs Wayland devraient être contents...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ca dérange les développeurs qui doivent se taper un double packaging et les utilisateurs quand ils ne trouvent pas de paquets pour leur distrib.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par reno . Évalué à 2.
Oh, je trouve aussi que c'est inutile/redondant, mais je me souviens des réactions à la LSB, genre "le rpm ne passera pas".
[^] # Re: Les dévs Wayland devraient être contents...
Posté par nicko . Évalué à 3.
Depuis quand les développeurs font les paquets ? C'est le boulot des mecs de la distrib ça non ?
[^] # Re: Les dévs Wayland devraient être contents...
Posté par nud . Évalué à 4.
Parfois les méchants vendeurs de logiciels propriétaires désirent rendre leur logiciel disponible sur une ou plusieurs plateformes Linux. C'est aussi vrai pour certains programmes mal foutus, trop récents ou qui évoluent trop vite (genre des jeux, qui répondent souvent aux trois critères par ailleurs)
[^] # Re: Les dévs Wayland devraient être contents...
Posté par zebra3 . Évalué à 3.
Posons-nous la question : comment font ces vendeurs pour fournir des logiciels sur les autres OS ?
Simple : ils payent des gens pour empaquetter aux formats MSI pour Windows et PKG pour Mac OS.
Pourquoi serait-ce différent pour les plus grosses distribution Linux ? Un RPM et un DEB, ce n'est pas plus compliqué que les formats précédent. Opera le fait bien, c'est pourtant pas l'une des plus grosses boîtes.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les dévs Wayland devraient être contents...
Posté par nud . Évalué à 2.
Ça reste chiant parce que le retour sur investissement est minime dans le cas de chaque distro linux individuelle, par rapport à Windows ou MacOSX.
Ceci dit le problème n'est pas que le format de paquets, car des paquets RPM de Suse et Fedora par exemple sont souvent incompatibles.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par zebra3 . Évalué à 5.
C'est pas un problème de format de paquets. Il y a des distributions majoritaires, y compris dans le pro. Il suffit de se limiter aux plus utilisées (genre RHEL et Debian/Ubuntu).
Tu peux parfaitement construire des paquets qui fonctionnent partout : il suffit de tout mettre dans /opt. D'ailleurs, c'est généralement ce qui est fait : Oracle installe tout dans un seul répertoire.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les dévs Wayland devraient être contents...
Posté par Anonyme . Évalué à 3.
Et inclure toutes les dependances dans le paquet.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par reno . Évalué à 2.
Ca fait quand même 2 fois plus d'efforts pour rien.
Et si tu vas par la, il est ou le probleme d'avoir Mir et ( Wayland et X et DirectFB et SurfaceFlinger ), ça n'en fait qu'un en plus.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Vu qu'il y a autant de systèmes de paquets et de distribs que d'étoiles dans le ciel, les "mecs de la distrib" ne peuvent pas tout faire.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par Misc (site web personnel) . Évalué à 5.
Peut être dans ce cas qu'il faudrait avoir moins de logiciels aussi, et moins de libs. Si tout le monde faisait juste du C et du python, ça simplifierais grandement les choses.
Mais on me dit que les gens prennent les distribs sur la base des softs présents, et donc qu'il y a une incitation à en mettre le plus possible. Et que bien sur, tout le monde est d'accord sur le fait d'avoir moins de distribs, moins de softs, à condition de rien perdre.
Quand on voit comment les efforts d'unification comme pulseaudio ( qui a permis de virer esd et artsd ) ou systemd, je me dit qu'en effet, tout le monde veut bien de l'unification, mais n'a aucune idée à quoi ça ressemble. Ou gnome-shell aussi ( car unifier, ça veut aussi dire avoir un nombre minimal de façon de faire ).
Chacun va justifier de "oui, mais je veux faire différemment", et ensuite ça va parler des nazis.
[^] # Re: Les dévs Wayland devraient être contents...
Posté par Marotte ⛧ . Évalué à 2.
Il y a quand même nettement moins de systèmes de packages que de distribs !
Si je prends les deux gros, deb et rpm, ils se partagent dans les combien en pourcentage d'utilisation par les distribs (rapporté aux nombres d'utilisateurs de chacune d'entre-elle) ? Une première application du théorème de Zenitram me donne du 90% !
# Mir, un serveur d'affichage de trop ?
Posté par vladislav askiparek . Évalué à 1.
Alors qu'un Mini Mir aurait suffit.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.