Il s'en prend à ceux qui mettent concrètement des bâtons dans
les roues du projet Mir. Ce n'est pas la même chose.
On est dans le domaine du logiciel libre. Le code est la, et le plus gros baton que tu puisses mettre dans les roues de quelqu'un, c'est de refuser de coopérer, ce qui force l'autre à faire le travail qui aurait pu être partagé. Mais ça reste aussi du logiciel libre, et personne ne te promet rien en terme de travail.
Refuser des patchs qui n'auraient pourtant pas engagé à grand
chose (vu que Canonical les maintiens), ce n'est pas pareil
que de juste troller sur Phoronix.
C'est une bonne remarque, et je comprends un peu mieux d'un coup la position de MS.
Si ça coute rien de maintenir les patchs pour le projet upstream, alors ça ne coute rien à Canonical de les maintenir, donc je ne voit pas comment l'argument peut être avancé pour dire qu'il y a des batons dans les roues.
Et si ça coute de maintenir les patchs à Canonical, ou du moins suffisament que ça soit vu comme "des batons dans les roues", alors le cout aurait été le même avec ou sans le commit.
Donc je pense que le point n'est pas de savoir si le patch est accepté ou pas, d'un point de vue technique car l'endroit ou est le patch n'a que peu d'importance, vu que dans les 2 cas, Canonical va faire le boulot. Par contre, avoir intel qui dit "on ne veut pas de mir", ça reste un camouflet pour la réputation de Canonical et pour le succès de son discours commercial.
Dire "intel soutiens notre initiative" est autrement mieux que "intel nous a dit non". Et c'est la que la position de Mark est malhonnête, car il parle de choses qui se passent d’après lui derrière les coulisses sans donner de raisons, et qui au final ont des actions sur ce que Canonical fait dans les coulisses.
IE, maintenant, je comprends un peu mieux d’où me viens le sentiment d'hypocrisie de l'article, ce qui prouve que j'ai bien fait de poster le journal car la discussion m'a permis de mettre le doigt dessus (et tu as le droit d'être pas d'accord avec ma vision, je précise)
What[ch] closely to see how competitors to Canonical torture
the English language in their efforts to justify how those
toolkits should support Windows but not Mir.
Vu sous cet angle, j'ai du mal à lui donner tort...
Si il parle de toolkit, c'est facile, il y a soit gtk, soit qt. Gtk s'oriente pour rester full linux, vu que la position est "on a pas des masses de ressources, y a que gnome qui fait des retours donc on s'oriente pour leurs besoins". Gtk sous windows est AMHA pas super bien maintenu.
Quand à QT, c'est pas maintenu par un concurrent de Canonical que je sache, donc sa pique est aussi incorrect.
Sauf si il parle de KDE, auquel cas j'invite les gens à lire les commentaires de l'article suivant :
Notamment le fait que Martin Gräßlin, l'un des seuls dev à avoir dit ouvertement "je ne supporterais pas mir tant que mir restera mono distribution" est aussi le mainteneur d'un des composants de kde qui n'est pas porté sous Windows.
Au passage, je ne vois pas non plus en quoi le support de windows est un souci, car ça touche plus de monde que Ubuntu par un ou deux ordres de magnitudes, et parce que Microsoft et Canonical sont maintenant des PPV vu la fermture du bug #1 sur launchpad.
[^] # Re: Mir
Posté par Misc (site web personnel) . En réponse au journal L'open source Tea party et Mark Shuttleworth. Évalué à 4.
On est dans le domaine du logiciel libre. Le code est la, et le plus gros baton que tu puisses mettre dans les roues de quelqu'un, c'est de refuser de coopérer, ce qui force l'autre à faire le travail qui aurait pu être partagé. Mais ça reste aussi du logiciel libre, et personne ne te promet rien en terme de travail.
C'est une bonne remarque, et je comprends un peu mieux d'un coup la position de MS.
Si ça coute rien de maintenir les patchs pour le projet upstream, alors ça ne coute rien à Canonical de les maintenir, donc je ne voit pas comment l'argument peut être avancé pour dire qu'il y a des batons dans les roues.
Et si ça coute de maintenir les patchs à Canonical, ou du moins suffisament que ça soit vu comme "des batons dans les roues", alors le cout aurait été le même avec ou sans le commit.
Donc je pense que le point n'est pas de savoir si le patch est accepté ou pas, d'un point de vue technique car l'endroit ou est le patch n'a que peu d'importance, vu que dans les 2 cas, Canonical va faire le boulot. Par contre, avoir intel qui dit "on ne veut pas de mir", ça reste un camouflet pour la réputation de Canonical et pour le succès de son discours commercial.
Dire "intel soutiens notre initiative" est autrement mieux que "intel nous a dit non". Et c'est la que la position de Mark est malhonnête, car il parle de choses qui se passent d’après lui derrière les coulisses sans donner de raisons, et qui au final ont des actions sur ce que Canonical fait dans les coulisses.
IE, maintenant, je comprends un peu mieux d’où me viens le sentiment d'hypocrisie de l'article, ce qui prouve que j'ai bien fait de poster le journal car la discussion m'a permis de mettre le doigt dessus (et tu as le droit d'être pas d'accord avec ma vision, je précise)
Si il parle de toolkit, c'est facile, il y a soit gtk, soit qt. Gtk s'oriente pour rester full linux, vu que la position est "on a pas des masses de ressources, y a que gnome qui fait des retours donc on s'oriente pour leurs besoins". Gtk sous windows est AMHA pas super bien maintenu.
Quand à QT, c'est pas maintenu par un concurrent de Canonical que je sache, donc sa pique est aussi incorrect.
Sauf si il parle de KDE, auquel cas j'invite les gens à lire les commentaires de l'article suivant :
https://plus.google.com/107555540696571114069/posts/76Nd9RSTZWp
Notamment le fait que Martin Gräßlin, l'un des seuls dev à avoir dit ouvertement "je ne supporterais pas mir tant que mir restera mono distribution" est aussi le mainteneur d'un des composants de kde qui n'est pas porté sous Windows.
Au passage, je ne vois pas non plus en quoi le support de windows est un souci, car ça touche plus de monde que Ubuntu par un ou deux ordres de magnitudes, et parce que Microsoft et Canonical sont maintenant des PPV vu la fermture du bug #1 sur launchpad.