Journal Mir, un serveur d'affichage de trop ?

Posté par (page perso) . Licence CC by-sa
Tags :
108
5
mar.
2013
Ce journal a été promu en dépêche : Mir, un serveur d’affichage de trop ?.

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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 10.

        ton article est plus constructif et approfondi ce qui apporte des éléments
        intéressants.

        Je confirme, tu fais chier patrick_g, t'aurais pu le poster plus tôt quand même :)

  • # Lennart Poettering

    Posté par (page perso) . Évalué à 10. Dernière modification le 05/03/13 à 11:08.

    Au sujet des trolls qui vont se déchainer, je dois avouer que le commentaire de Lennart m'a fait beaucoup rire :

    I am sure "Mir" is going to be a project with a fantastic future, just like bazaar, or Upstart, or Project Harmony before it.

    • [^] # Re: Lennart Poettering

      Posté par . Évalué à 8.

      Et il continue avec :

      Also, isn't Mir this thing that burnt and crashed into the South Pacific Ocean near Fiji on 23rd March, 2001, after some dudes in Russia flipped a switch after they gave it up?

      This must be metaphor for something, haven't figured out for what yet, though, must be something deeper than "This software includes a space toilet and Canonical will give it up one day, when it will burn and crash and then we'll be in a south pacific paradise setting."

    • [^] # Re: Lennart Poettering

      Posté par (page perso) . É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 . Évalué à 9.

    le projet de Mark Shuttleworth

    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:

    Mark in 2010: "we evaluated the cost of building a new display manager, informed by the lessons learned in Wayland. We came to the conclusion that any such effort would only create a hard split in the world which wasn’t worth the cost of having done it. There are issues with Wayland, but they seem to be solvable, we’d rather be part of solving them than chasing a better alternative. So Wayland it is."

    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 (page perso) . Évalué à 8.

      Wayland/Weston est en développement depuis plus d'un an

      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 (page perso) . É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 . É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 . Évalué à 10.

    Il s'appelera Mir Express.

    /o\

    BeOS le faisait il y a 15 ans !

  • # Discussion entre un dev MIR et les dev Wayland

    Posté par (page perso) . Évalué à 5.

    • [^] # Re: Discussion entre un dev MIR et les dev Wayland

      Posté par . É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 (page perso) . Évalué à 6. Dernière modification le 05/03/13 à 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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 4.

          Non Red Hat ne force rien sur personne.

          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 . É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 . Évalué à 1.

          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.

          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 . É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 . Évalué à 10.

            rpm était bien à la ramasse techniquement par rapport à deb

            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 . Évalué à 9. Dernière modification le 05/03/13 à 21:32.

        le probleme majeur c'est que wayland c'est du RH

        Pas un problème, Wayland n'a jamais été un projet RH y compris lorsque Kristian bossait chez RH (il est actuellement chez Intel)

        historiquement parlant Canonical s'est toujours fait rejeter toute ses propositions de changement

        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.

        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

        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).

        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

        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 (page perso) . Évalué à 2.

          Le problème, il se situe au niveau du management de Canonical plutôt qui ne laisse aucune place à la collaboration upstream.

          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 (page perso) . É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 . É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 . É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.

  • # Quelques infos

    Posté par . É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 . É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 . É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:

        927

        • [^] # Re: Quelques infos

          Posté par . É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 . Évalué à 5.

            En même temps, la situation évoquée se retrouve souvent…

  • # Google +

    Posté par . É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 : http://linuxfr.org/news/cpp17-exprime-la-virgule-flottante-en-hexadecimal-et-offre-des-cadeaux-aux-lecteurs-de-linuxfr-org#comment-1686201

    • [^] # Re: Google +

      Posté par . Évalué à 8.

      Ce n'est pas toi..

    • [^] # Re: Google +

      Posté par (page perso) . É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 (page perso) . Évalué à 5.

        Par contre, à titre personnel, je ne participe ni à Google+ ni à Facebook. Je trouve que c'est bonnet blanc et blanc bonnet.

        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 . Évalué à 3.

          A l'utilisation, je trouve G+ beaucoup plus épurée et simple que Facebook, le flux, rien que le flux.

          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 (page perso) . É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 (page perso) . Évalué à 7.

        probablement parce que Google est dans l'ensemble très amical vis-à-vis du libre

        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.

        En comparaison, Facebook ou Twitter n'ont quasiment rien apporté aux logiciels libres.

        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 . Évalué à 3.

          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é.

          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 (page perso) . Évalué à 0.

            Google a juste développé deux OS basés sur Linux

            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.

            un navigateur

            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 (page perso) . Évalué à 5.

              Une GUI pour Webkit, tu veux dire.

              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 (page perso) . Évalué à 2.

                À égalité avec Apple, donc Apple c'est le bien, comme Google ?

                • [^] # Re: Google +

                  Posté par . É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 (page perso) . É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 (page perso) . É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.

                      • [^] # Re: Google +

                        Posté par (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . Évalué à 3.

                      « Allez, Salut ! et merci pour tout le poisson »

                      • [^] # Re: Google +

                        Posté par . Évalué à 1.

                        "Comment ça, il est pas frais mon poisson ? "

                        PAFFFF !!!

            • [^] # Re: Google +

              Posté par . Évalué à 7.

              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.

              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 . É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 . É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 (page perso) . Évalué à 8.

        Et personnellement donner mon vrai nom sur FB ou g+, c'est hors de question.

        Ton réseau de connaissances en dit bien plus sur toi que ton vrai nom.

        • [^] # Re: Google +

          Posté par . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . Évalué à 2.

    De nombreuses critiques ont été émises sur le caractère impénétrable de son code

    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.

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Confusion

      Posté par (page perso) . É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 (page perso) . Évalué à 4.

        Et des softs commerciaux fermés.

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: Confusion

        Posté par . Évalué à 2. Dernière modification le 06/03/13 à 11:57.

        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.

        Il y a aussi android-xserver
        (et aussi apparemment d'autres implémentations comme weirdx

  • # Nique les zoulous

    Posté par . Évalué à -10. Dernière modification le 05/03/13 à 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.

  • # Les dévs Wayland devraient être contents...

    Posté par . É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 . É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 (page perso) . Évalué à 4.

        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)

        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.

        http://devnewton.bci.im

        • [^] # Re: Les dévs Wayland devraient être contents...

          Posté par . É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 . É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 . É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 . É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 . É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 . Évalué à 5.

                  Ça reste chiant parce que le retour sur investissement est minime dans le cas de chaque distro linux individuelle, par rapport à Windows ou MacOSX.

                  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).

                  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.

                  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 . Évalué à 2.

                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.

                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 (page perso) . É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.

            http://devnewton.bci.im

            • [^] # Re: Les dévs Wayland devraient être contents...

              Posté par (page perso) . É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 . Évalué à 2.

              il y a autant de systèmes de paquets et de distribs que d'étoiles dans le ciel

              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 . Évalué à 1.

    Alors qu'un Mini Mir aurait suffit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.