GCJ n'évolue plus depuis la libération d'openJDK, la plupart des développeurs qui travaillaient dessus sont passés sur openJDK. GCJ s'est arrêté à Java 5 (pas tout à fait à 100%) alors que Java 8 pointe le bout de son nez et que Java 6 est passé en support communautaire.
Mon point aussi c'est de savoir s'il y a un argument solide pour dénigrer ubuntu server,
où tu as vu que je dénigrais Ubuntu Server ? Je mettais en valeur le fait que Debian gérait aussi très bien LXC (au passage, la plupart des personnes qui utilisent Ubuntu Server serait tout aussi bien servi par Debian, voire mieux).
Et tu noteras que j'ai aussi pointé du doigt le support foireux dans Fedora.
Mais ça reste la solution la plus simple pour faire tourner des containers LXC.
C'est tout aussi simple sous Debian et c'est eux qui ont fait le gros du boulot (rendons à César ce qui est à César) et c'est un poil plus léger et stable qu'Ubuntu Server.
Pour être honnête, openSUSE a fait un très bon boulot d'intégration également de LXC qui vaut largement Debian/Ubuntu (avec intégration dans YAST), sous Fedora le userland LXC est régulièrement pété (d'une part à cause des lennarteries - systemd et LXC reposent fortement sur cgroups, quelques interactions foireuses-, d'autre part, le paquet est pas à jour)
surfaceflinger est le serveur d'affichage le plus utilisé (ou presque)
SurfaceFlinger est spécifique à Android, il n'est pas généraliste et d'ailleurs Google est prêt à envisager de le bazarder quand Wayland sera finalisé. C'est plutôt une question de timing, Google avait besoin d'un serveur d'affichage léger et moderne pour Android dans un délai très court, et Wayland a des contraintes dont Google se fout (notamment le support d'OpenGL ES qui est garantit sous Android)
Wayland est une vrai cathédrale à l'ancienne avec 5 ans pour arrivé en version 1.0 et aucune utilisation hors de ceux qui ont vraiment voulu tester. Là où SF et Mir sont des bazar qui cherchent plus à sortir des versions régulière qui à ce qu'elles ne soient pas parfaite.
Euh Mir développé par Canonical dans son coin, ça ressemble plus à un développement en cathédrale, et le CLA imposé garantit que ça ne sera pas un développement en bazar. Wayland a sorti des versions régulières les backends Wayland de Gtk, Qt, EFL n'ont pas attendu la version 1.0. Personne en dehors de krh n'a vraiment la main sur le projet, contrairement à Mir.
d'ailleurs à ce sujet là j'ai l'impression que les développeurs de Wayland sont face à la peur du programmeur, ils ne veulent pas sortir plus tôt pour ne pas avoir des remarques sur des trucs qu'ils n'ont pas totalement fini. Le problème c'est qu'un logiciel n'est jamais totalement fini.
Sortir un remplaçant à X11 ne se fera pas du jour au lendemain, y a encore beaucoup de points à régler avant le passage en production (sécurité, stabilité du protocole, performances, support matériel, etc …). Il faut voir que tant que les "Release Blockers" ne seront pas levés, on ne peut pas faire le grand saut.
Personnellement je préfère juger sur pièce pour voir si Mir ou Wayland s'en sort mieux et pour le moment on a rien.
Euh, Mir y a rien du tout à part des démos pourries, Wayland ça tourne depuis un moment et c'est assez stable depuis un moment, la plupart des toolkits le supportent depuis quelques temps.
Le mode de développement de Mir certifie que ça restera un projet Canonical-only qui peinera à rattraper son gros retard sur Wayland, là où Wayland a déjà une communauté solide et le soutien de l'industrie et des éditeurs mais surtout de la communauté Xorg.
La différence c'est que les licences BSD mettent tout le monde à égalité, pas le CLA Canonical.
Supposons que A est un contributeur majeur au projet LeChat de Canonical (supposons que A et Canonical ait contribué 50% du code chacun) sous GPLv2
A et Canonical ont exactement les mêmes droits dans le cadre de la licence GPLv2 de LeChat
A possède le copyright sur le code qu'il a contribué et peut en faire de qu'il veut (idem pour Canonical)
A cède une licence perpétuelle, irrévocable, transférable et sans royalties à Canonical sur son code (idem pour les brevets possédés par A couvrant le code en question). Canonical fait donc ce qu'il veut de l'ensemble de l'œuvre. Aucune symétrie pour A qui reste limité par la GPLv2 pour la partie du code contribuée par Canonical
Cette asymétrie explique déjà pourquoi bon nombre de sociétés gravitant dans le monde de l'open source sont rebutés à l'idée de collaborer sur des projets Canonical d'autant plus qu'en pratique, elles peuvent mettre plus de ressources que Canonical sur les projets en question.
On a eu le même problème avec le CLA FedoraProject.org et il a été modifié pour que la licence par défaut pour le code soit MIT (les contributeurs peuvent choisir une licence libre acceptable par le projet) et CC-By-SA 3.0 pour tout ce qui n'est pas code, afin de garantir cette symétrie. La plupart des projets initiés par RH évite de devoir requérir ce genre de CLA asymétrique afin d'encourager les contributions externes (personnels ou corporate), par exemple systemd ou libvirt n'en ont pas.
Un exemple à la con: OpenStack exige un CLA similaire (principalement pour des raisons légales), mais il offre une licence Apache 2.0 qui garantit que tout les contributeurs aient les mêmes droits sur l'œuvre, et depuis l'année dernière la gouvernance est partagée par tout les contributeurs. Résultat: ça encourage les contributions externes.
Canonical a décidé que sa couche de compatibilité Amazon pour OpenStack (AWSOME) serait sous Affero GPLv3 + CLA pour les contributeurs. Résultat: personne ne s'est intéressé au projet, les gens ont préféré directement contribuer sur la couche de compatibilité AWS d'OpenStack pourtant bien moins avancée. Ou Deltacloud de RH qui est un projet Apache Top Level qui exige un CLA Apache. On revient donc au problème de l'acteur de confiance, il est plus facile de faire confiance à la Fondation Apache qu'à Red Hat pour céder une licence perpétuelle etc … et la licence est suffisamment permissive pour ne "léser" personne.
Euh, je fais tourner ces services sans problèmes, et ce dès F14 (systemd est devenu l'init par défaut de Fedora à partir de F15). Je pense que tu as un autre problème, je ne puis que te conseiller de faire un rapport de bugs si ce n'est pas fait, les mainteneurs sont très réactifs.
De manière générale, systemd a permis de résoudre bon nombre de bugs (support du multi-sièges, hibernation etc …), même si c'est surtout aux fonctionnalités non liés directement à l'init à proprement parler.
Upstart n'était pas dénué de bugs, systemd a quelques soucis dans la gestion de certains daemons bien pourris -au sens qu'ils ne respectent pas les conventions classiques des daemons Unix- comme HAProxy, mais c'est une amélioration..
Canonical espère donc que steam et les autres devs de programmes payants ou simplement propriétaires fassent pression sur nvidia, … pour qu'ils développent des pilots pour Mir.
ça fait des années qu'on fait pression sur nVidia pour qu'ils libèrent les specifications ou du moins acceptent de répondre aux questions des développeurs de Nouveau. À votre avis, il est plus facile d'obliger nVidia à développer une version spécifique à Ubuntu de leur pilote ou de forcer Canonical à livrer Wayland ?
Je leur souhaite bon courage !
Lol, mais je ferais remarquer une différence majeure: Wayland est ouvert, Unix était fermé, Wayland rassemble, Unix était divisé, Wayland est en pleine ascension, Unix entamait son déclin. Mir est plus fermé que Wayland (CLA oblige), Mir divise, Mir n'apporte rien de novateur et a été développé dans son coin sans volonté de s'ouvrir.
Les prémisses étant différentes, je puis légitimement croire que les conséquences le seront aussi ;)
Tout à fait, comme RedHat avec PulseAudio et SystemD par exemple
J'aimerais qu'on me démontre en quoi Red Hat a spécialement la main sur pulseaudio et systemd ?
PA: les derniers mainteneurs ne sont pas employés par Red Hat (Colin Guthrie bosse chez mandriva, Tanu Kaskinen n'est pas un red hatter), et il y a des commits venant de différentes sociétés (dont Collabora, Canonical et divers boites faisant de l'embarqué). Par ailleurs, Lennart avait commencé à travailler sur Polypaudio en 2004, soit avant d'être recruté par RH.
systemd: on a tendance à l'oublier mais systemd a deux papas: Lennart et Kay, Kay bossait à l'époque pour SUSE (maintenant, il est passé chez RH entre temps) mais idem, le projet a démontré être ouvert à tous.
On notera qu'aucun de ses projets ne requiert de céder son copyright ou propose une licence non-copyleft permettant de "propriétariser" le code.
Je partage ton opinion que RH cherche tout autant que Canonical à contrôler ce qu'ils éditent, mais une différence majeure:
RH cherche à embaucher des développeurs clés et privilégie le travail en upstream (ce n'est pas le cas de toutes les équipes, mais c'est la politique maison). Ça nécessite de proposer les conditions nécessaires et suffisantes pour attirer puis garder des développeurs qui sont pour la plupart très sollicités que ce soit sur le plan financier, conditions de travail et éthiques (oui, la plupart des développeurs libristes préfèrent être un peu moins payés et garder leur éthique). On pourrait en dire autant de SUSE, Collabora, Lanedo etc …
Canonical cherche à garder un contrôle sur le code en imposant un CLA et refuse de partager la gouvernance du projet que ce soit Upstart, Launchpad, bazaar, Unity etc …
Certes, ils ont le même buts - et sont aussi pourris l'un que l'autre - mais ils n'ont pas choisi la même stratégie.
C'est vrai qu'ils ont l'air vraiment d'être des gros mauvais…
Prends note que je parle de la nullité technique de Mir et de l'**inexpérience** des développeurs de Mir. Certes, j'aurais dû précisé pour les malcomprenants (ou qui ont la mémoire courte) que ça ne veut pas dire que les développeurs de Mir soient mauvais.
Hein, que les développeurs de Mir n'aient aucune expérience concrète dans le développement de serveurs d'affichage, ce n'est pas une tare, c'est un fait. Développer un serveur d'affichage, ça demande un bon nombre de compétences et beaucoup de boulot, vouloir rattraper Wayland qui a 5 ans d'avance, rassemble la plupart des spécialistes du domaines est un combat perdu d'avance pour des développeurs qui doivent rattraper en // leur retard.
Les personnes ayant une expérience dans ce domaine sont assez rares et très recherchées (développeur X/Wayland, ça paie bien mieux que développeur noyau et beaucoup moins de concurrence, un conseil aux étudiants, faites des Google SoC sur Xorg ou Wayland)
Tu noteras que Slackware a toujours un init de type BSD et refuse PAM.
Debian
Debian n'a pas refusé systemd, la seule raison qui empêche systemd d'être par défaut dans Jessie (trop tard pour Wheezy) est le support des noyaux alternatifs (et ça reste assez controversé). Il est probable que pour certaines installations de Jessie, systemd soit proposé par défaut
La majorité des distros GNU/Linux est passé ou envisage sérieusement de passer à systemd, c'est un fait. Il y a aujourd'hui beaucoup plus de distros qui utilisent systemd qu'il n'y a eu de distros utilisant upstart (y compris des distros qui auparavant utilisait un init type BSD)
il a provoqué des milliers de réactions hostiles (comme Mir)
La différence est qui est à l'origine des réactions hostiles, les critiques de Mir viennent de gens qui ont l'expérience et le bagage technique pour formuler des critiques pertinentes. Ça n'a pas été le cas pour systemd, mais James Scott Remnant le mainteneur d'Upstart avait reconnu que systemd avait une valeur ajouté par rapport à Upstart (et bizarrement, la roadmap d'Upstart semble plutôt tenter de rattraper systemd que de se démarquer vraiment de lui).
Une autre différence: la nullité technique de Mir et l'inexpérience des personnes derrière, ce qui n'était pas le cas de systemd qui était déjà bien plus intéressant qu'Upstart (mais rendons à César ce qui est à César, c'est en bonne partie dû au retour d'expérience d'Upstart qui reste un bon logiciel)
Pourquoi systemd ? Parce que Canonical a imposé un CLA imposant le partage du copyright (or ça suppose d'avoir confiance en l'entité et le capital confiance de Canonical est assez faible) et a toujours refusé de partager la direction du projet.
Il aurait lâché un peu de lest qu'aujourd'hui la situation serait complétement différente. Rien ne les oblige à passer à systemd, mais de fait, ils s'éloigneront de plus en plus du reste des distros GNU/Linux et ils y auront fortement contribué.
Euh, tu tiens d'où le fait que Nvidia veut devenir fondeur ?
ça arrivera tôt ou tard, le partenaire-fondeur actuel TSMC s'est révélé assez deçevant sur sa politique tarifaire et ses évolutions techniques. Si nVidia veut concurrencer Intel, il faudra soit racheter un fondeur (ou du moins des parts dans l'outil de production comme l'a fait AMD) ne serait-ce que pour garantir sa marge de manoeuvre technique et financière.
Oui, pas besoin d'être grand clerc (tu noteras que je ne prétends pas l'être non plus).
Pour répondre à ta question, nVidia ne disparaitra pas à cause du saint bâton de St Ignucius-Moïse mais plutôt à cause de la convergence CPU/GPU. Convergence qui fait suffisamment flipper nVidia pour devenir un fondeur CPU et de pousser à fond ARM.
Sinon c'était sympa tes vacances sur le pic de Bugarach ?
Supaire, j'ai prié pour le retour de Dennis Ritchie sur Terre avec mes amies hippies tout nu sous la pleine lune.
Je les en crois capable, mais il a fallu presque 5 ans pour que Wayland arrive en version 1.0 avec des gens expérimentés. À ton avis, il faudra combien de temps à Mir pour arriver au même point ? Avec une équipe qui devra se former en même temps, et sans aucun soutien autre que Canonical ?
Crois-tu que Wayland attendra gentiment que Mir avance ? VOyons les choses en face, Mir est un projet voué à l'échec, la question est de savoir si il aura un pouvoir nuisible ou non sur le développement de Wayland (je ne parle pas de dispersion des forces, mais plutôt de semer la confusion en direction des constructeurs, éditeurs logiciels et de la communauté).
Je pense en particulier à nVidia qui pour l'instant ne s'est pas jeté sur Wayland - et sans eux, assez peu de choses vont pouvoir se passer.
On s'en fout de nVidia, ils ne jouent pas le jeu du logiciel et ils auront disparu d'ici 10 ans de toute façon.
Il y a un consensus des acteurs du logiciels libres et c'est la seule chose qui compte.
Une alternative, Mir, démarre avant que Wayland soit massivement utilisé ? Tant mieux.
C'est oublier plusieurs choses:
* X11 est bien implanté et sans un consensus de l'ensemble des acteurs se sera très difficile à le déloger. Wayland a réussi à obtenir ce consensus
* Les personnes derrière Mir n'ont même pas essayé de discuter avec Wayland pour voir si il y avait possibilité de convergence.
* Le rationale de Mir est bourré d'inepties et de conneries sur Wayland et on se pose légitimement la question de savoir si les développeurs de Mir ont les compétences pour développer un tel projet.
* Techniquement parlant, Mir est une blague (sinistre)
Ici Canonical n'a même pas l'excuse du "méchant Red Hat qui bloque toutes nos contributions par mesquinerie". Mir est non seulement un gâchis, mais il pourrait se révéler néfaste à l'avenir du bureau libre, en brouillant les signaux.
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: et java ?
Posté par GeneralZod . En réponse à la dépêche La version 4.8 du compilateur GCC est disponible. Évalué à 10.
GCJ n'évolue plus depuis la libération d'openJDK, la plupart des développeurs qui travaillaient dessus sont passés sur openJDK. GCJ s'est arrêté à Java 5 (pas tout à fait à 100%) alors que Java 8 pointe le bout de son nez et que Java 6 est passé en support communautaire.
[^] # Re: Ubun.... QUOI ????
Posté par GeneralZod . En réponse à la dépêche Gruik fait sa tête de lard. Évalué à 2.
où tu as vu que je dénigrais Ubuntu Server ? Je mettais en valeur le fait que Debian gérait aussi très bien LXC (au passage, la plupart des personnes qui utilisent Ubuntu Server serait tout aussi bien servi par Debian, voire mieux).
Et tu noteras que j'ai aussi pointé du doigt le support foireux dans Fedora.
[^] # Re: Ubun.... QUOI ????
Posté par GeneralZod . En réponse à la dépêche Gruik fait sa tête de lard. Évalué à 10.
C'est tout aussi simple sous Debian et c'est eux qui ont fait le gros du boulot (rendons à César ce qui est à César) et c'est un poil plus léger et stable qu'Ubuntu Server.
Pour être honnête, openSUSE a fait un très bon boulot d'intégration également de LXC qui vaut largement Debian/Ubuntu (avec intégration dans YAST), sous Fedora le userland LXC est régulièrement pété (d'une part à cause des lennarteries - systemd et LXC reposent fortement sur cgroups, quelques interactions foireuses-, d'autre part, le paquet est pas à jour)
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 6.
SurfaceFlinger est spécifique à Android, il n'est pas généraliste et d'ailleurs Google est prêt à envisager de le bazarder quand Wayland sera finalisé. C'est plutôt une question de timing, Google avait besoin d'un serveur d'affichage léger et moderne pour Android dans un délai très court, et Wayland a des contraintes dont Google se fout (notamment le support d'OpenGL ES qui est garantit sous Android)
Euh Mir développé par Canonical dans son coin, ça ressemble plus à un développement en cathédrale, et le CLA imposé garantit que ça ne sera pas un développement en bazar. Wayland a sorti des versions régulières les backends Wayland de Gtk, Qt, EFL n'ont pas attendu la version 1.0. Personne en dehors de krh n'a vraiment la main sur le projet, contrairement à Mir.
Sortir un remplaçant à X11 ne se fera pas du jour au lendemain, y a encore beaucoup de points à régler avant le passage en production (sécurité, stabilité du protocole, performances, support matériel, etc …). Il faut voir que tant que les "Release Blockers" ne seront pas levés, on ne peut pas faire le grand saut.
Euh, Mir y a rien du tout à part des démos pourries, Wayland ça tourne depuis un moment et c'est assez stable depuis un moment, la plupart des toolkits le supportent depuis quelques temps.
Le mode de développement de Mir certifie que ça restera un projet Canonical-only qui peinera à rattraper son gros retard sur Wayland, là où Wayland a déjà une communauté solide et le soutien de l'industrie et des éditeurs mais surtout de la communauté Xorg.
[^] # Re: Mouais
Posté par GeneralZod . En réponse au journal Canonical/Ubuntu ou l'allégorie de la grenouille. Évalué à 4.
La différence c'est que les licences BSD mettent tout le monde à égalité, pas le CLA Canonical.
Supposons que A est un contributeur majeur au projet LeChat de Canonical (supposons que A et Canonical ait contribué 50% du code chacun) sous GPLv2
A et Canonical ont exactement les mêmes droits dans le cadre de la licence GPLv2 de LeChat
A possède le copyright sur le code qu'il a contribué et peut en faire de qu'il veut (idem pour Canonical)
A cède une licence perpétuelle, irrévocable, transférable et sans royalties à Canonical sur son code (idem pour les brevets possédés par A couvrant le code en question). Canonical fait donc ce qu'il veut de l'ensemble de l'œuvre. Aucune symétrie pour A qui reste limité par la GPLv2 pour la partie du code contribuée par Canonical
Cette asymétrie explique déjà pourquoi bon nombre de sociétés gravitant dans le monde de l'open source sont rebutés à l'idée de collaborer sur des projets Canonical d'autant plus qu'en pratique, elles peuvent mettre plus de ressources que Canonical sur les projets en question.
On a eu le même problème avec le CLA FedoraProject.org et il a été modifié pour que la licence par défaut pour le code soit MIT (les contributeurs peuvent choisir une licence libre acceptable par le projet) et CC-By-SA 3.0 pour tout ce qui n'est pas code, afin de garantir cette symétrie. La plupart des projets initiés par RH évite de devoir requérir ce genre de CLA asymétrique afin d'encourager les contributions externes (personnels ou corporate), par exemple systemd ou libvirt n'en ont pas.
Un exemple à la con: OpenStack exige un CLA similaire (principalement pour des raisons légales), mais il offre une licence Apache 2.0 qui garantit que tout les contributeurs aient les mêmes droits sur l'œuvre, et depuis l'année dernière la gouvernance est partagée par tout les contributeurs. Résultat: ça encourage les contributions externes.
Canonical a décidé que sa couche de compatibilité Amazon pour OpenStack (AWSOME) serait sous Affero GPLv3 + CLA pour les contributeurs. Résultat: personne ne s'est intéressé au projet, les gens ont préféré directement contribuer sur la couche de compatibilité AWS d'OpenStack pourtant bien moins avancée. Ou Deltacloud de RH qui est un projet Apache Top Level qui exige un CLA Apache. On revient donc au problème de l'acteur de confiance, il est plus facile de faire confiance à la Fondation Apache qu'à Red Hat pour céder une licence perpétuelle etc … et la licence est suffisamment permissive pour ne "léser" personne.
[^] # Re: Croa
Posté par GeneralZod . En réponse au journal Canonical/Ubuntu ou l'allégorie de la grenouille. Évalué à 3.
Au temps pour moi, mes excuses à Colin Guthrie. :)
[^] # Re: Systemd ou système qui marche…
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 5.
Euh, je fais tourner ces services sans problèmes, et ce dès F14 (systemd est devenu l'init par défaut de Fedora à partir de F15). Je pense que tu as un autre problème, je ne puis que te conseiller de faire un rapport de bugs si ce n'est pas fait, les mainteneurs sont très réactifs.
De manière générale, systemd a permis de résoudre bon nombre de bugs (support du multi-sièges, hibernation etc …), même si c'est surtout aux fonctionnalités non liés directement à l'init à proprement parler.
Upstart n'était pas dénué de bugs, systemd a quelques soucis dans la gestion de certains daemons bien pourris -au sens qu'ils ne respectent pas les conventions classiques des daemons Unix- comme HAProxy, mais c'est une amélioration..
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 2.
ça fait des années qu'on fait pression sur nVidia pour qu'ils libèrent les specifications ou du moins acceptent de répondre aux questions des développeurs de Nouveau. À votre avis, il est plus facile d'obliger nVidia à développer une version spécifique à Ubuntu de leur pilote ou de forcer Canonical à livrer Wayland ?
Je leur souhaite bon courage !
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 1.
Lol, mais je ferais remarquer une différence majeure: Wayland est ouvert, Unix était fermé, Wayland rassemble, Unix était divisé, Wayland est en pleine ascension, Unix entamait son déclin. Mir est plus fermé que Wayland (CLA oblige), Mir divise, Mir n'apporte rien de novateur et a été développé dans son coin sans volonté de s'ouvrir.
Les prémisses étant différentes, je puis légitimement croire que les conséquences le seront aussi ;)
[^] # Re: Croa
Posté par GeneralZod . En réponse au journal Canonical/Ubuntu ou l'allégorie de la grenouille. Évalué à 7. Dernière modification le 08 mars 2013 à 17:02.
J'aimerais qu'on me démontre en quoi Red Hat a spécialement la main sur pulseaudio et systemd ?
PA: les derniers mainteneurs ne sont pas employés par Red Hat (Colin Guthrie bosse chez mandriva, Tanu Kaskinen n'est pas un red hatter), et il y a des commits venant de différentes sociétés (dont Collabora, Canonical et divers boites faisant de l'embarqué). Par ailleurs, Lennart avait commencé à travailler sur Polypaudio en 2004, soit avant d'être recruté par RH.
systemd: on a tendance à l'oublier mais systemd a deux papas: Lennart et Kay, Kay bossait à l'époque pour SUSE (maintenant, il est passé chez RH entre temps) mais idem, le projet a démontré être ouvert à tous.
On notera qu'aucun de ses projets ne requiert de céder son copyright ou propose une licence non-copyleft permettant de "propriétariser" le code.
Je partage ton opinion que RH cherche tout autant que Canonical à contrôler ce qu'ils éditent, mais une différence majeure:
RH cherche à embaucher des développeurs clés et privilégie le travail en upstream (ce n'est pas le cas de toutes les équipes, mais c'est la politique maison). Ça nécessite de proposer les conditions nécessaires et suffisantes pour attirer puis garder des développeurs qui sont pour la plupart très sollicités que ce soit sur le plan financier, conditions de travail et éthiques (oui, la plupart des développeurs libristes préfèrent être un peu moins payés et garder leur éthique). On pourrait en dire autant de SUSE, Collabora, Lanedo etc …
Canonical cherche à garder un contrôle sur le code en imposant un CLA et refuse de partager la gouvernance du projet que ce soit Upstart, Launchpad, bazaar, Unity etc …
Certes, ils ont le même buts - et sont aussi pourris l'un que l'autre - mais ils n'ont pas choisi la même stratégie.
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 5.
C'est une question de confiance au final, il est plus facile de faire confiance à la FSF qu'à Canonical (ou toute autre entité commerciale)
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 2.
Prends note que je parle de la nullité technique de Mir et de l'**inexpérience** des développeurs de Mir. Certes, j'aurais dû précisé pour les malcomprenants (ou qui ont la mémoire courte) que ça ne veut pas dire que les développeurs de Mir soient mauvais.
Hein, que les développeurs de Mir n'aient aucune expérience concrète dans le développement de serveurs d'affichage, ce n'est pas une tare, c'est un fait. Développer un serveur d'affichage, ça demande un bon nombre de compétences et beaucoup de boulot, vouloir rattraper Wayland qui a 5 ans d'avance, rassemble la plupart des spécialistes du domaines est un combat perdu d'avance pour des développeurs qui doivent rattraper en // leur retard.
Les personnes ayant une expérience dans ce domaine sont assez rares et très recherchées (développeur X/Wayland, ça paie bien mieux que développeur noyau et beaucoup moins de concurrence, un conseil aux étudiants, faites des Google SoC sur Xorg ou Wayland)
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 0.
Tu noteras que Slackware a toujours un init de type BSD et refuse PAM.
Debian n'a pas refusé systemd, la seule raison qui empêche systemd d'être par défaut dans Jessie (trop tard pour Wheezy) est le support des noyaux alternatifs (et ça reste assez controversé). Il est probable que pour certaines installations de Jessie, systemd soit proposé par défaut
La majorité des distros GNU/Linux est passé ou envisage sérieusement de passer à systemd, c'est un fait. Il y a aujourd'hui beaucoup plus de distros qui utilisent systemd qu'il n'y a eu de distros utilisant upstart (y compris des distros qui auparavant utilisait un init type BSD)
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 2.
La différence est qui est à l'origine des réactions hostiles, les critiques de Mir viennent de gens qui ont l'expérience et le bagage technique pour formuler des critiques pertinentes. Ça n'a pas été le cas pour systemd, mais James Scott Remnant le mainteneur d'Upstart avait reconnu que systemd avait une valeur ajouté par rapport à Upstart (et bizarrement, la roadmap d'Upstart semble plutôt tenter de rattraper systemd que de se démarquer vraiment de lui).
Une autre différence: la nullité technique de Mir et l'inexpérience des personnes derrière, ce qui n'était pas le cas de systemd qui était déjà bien plus intéressant qu'Upstart (mais rendons à César ce qui est à César, c'est en bonne partie dû au retour d'expérience d'Upstart qui reste un bon logiciel)
[^] # Re: Pourquoi pas ? Mais...
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 1.
Pourquoi systemd ? Parce que Canonical a imposé un CLA imposant le partage du copyright (or ça suppose d'avoir confiance en l'entité et le capital confiance de Canonical est assez faible) et a toujours refusé de partager la direction du projet.
Il aurait lâché un peu de lest qu'aujourd'hui la situation serait complétement différente. Rien ne les oblige à passer à systemd, mais de fait, ils s'éloigneront de plus en plus du reste des distros GNU/Linux et ils y auront fortement contribué.
[^] # Re: Canonical est-elle encore une entreprise souhaitant développer le monde open source ?
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 3.
Le discours marketing de Canonical ?
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 0.
ça arrivera tôt ou tard, le partenaire-fondeur actuel TSMC s'est révélé assez deçevant sur sa politique tarifaire et ses évolutions techniques. Si nVidia veut concurrencer Intel, il faudra soit racheter un fondeur (ou du moins des parts dans l'outil de production comme l'a fait AMD) ne serait-ce que pour garantir sa marge de manoeuvre technique et financière.
Oui, pas besoin d'être grand clerc (tu noteras que je ne prétends pas l'être non plus).
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 4.
Pour répondre à ta question, nVidia ne disparaitra pas à cause du saint bâton de St Ignucius-Moïse mais plutôt à cause de la convergence CPU/GPU. Convergence qui fait suffisamment flipper nVidia pour devenir un fondeur CPU et de pousser à fond ARM.
Supaire, j'ai prié pour le retour de Dennis Ritchie sur Terre avec mes amies hippies tout nu sous la pleine lune.
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 10.
Je les en crois capable, mais il a fallu presque 5 ans pour que Wayland arrive en version 1.0 avec des gens expérimentés. À ton avis, il faudra combien de temps à Mir pour arriver au même point ? Avec une équipe qui devra se former en même temps, et sans aucun soutien autre que Canonical ?
Crois-tu que Wayland attendra gentiment que Mir avance ? VOyons les choses en face, Mir est un projet voué à l'échec, la question est de savoir si il aura un pouvoir nuisible ou non sur le développement de Wayland (je ne parle pas de dispersion des forces, mais plutôt de semer la confusion en direction des constructeurs, éditeurs logiciels et de la communauté).
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à -3.
On s'en fout de nVidia, ils ne jouent pas le jeu du logiciel et ils auront disparu d'ici 10 ans de toute façon.
Il y a un consensus des acteurs du logiciels libres et c'est la seule chose qui compte.
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 1.
Si ils avaient pris le temps de discuter avec les développeurs de Wayland ou d'étudier le code de celui-ci, ils ne seraient pas trompés à ce point.
Relis les réactions, notamment celle de Dave Airlie (encore une autre So maybe I'm being too cynical and Hanlon's razor applies, "Never attribute to malice that which is adequately explained by stupidity".
Oui, les développeurs de Mir se sont ridiculisés, ça ne veut pas dire qu'ils soient incompétents, juste qu'ils n'ont pas les compétences et l'expérience pour développer un serveur d'affichage.
[^] # Re: Une alternative ? Tant mieux
Posté par GeneralZod . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 9.
C'est oublier plusieurs choses:
* X11 est bien implanté et sans un consensus de l'ensemble des acteurs se sera très difficile à le déloger. Wayland a réussi à obtenir ce consensus
* Les personnes derrière Mir n'ont même pas essayé de discuter avec Wayland pour voir si il y avait possibilité de convergence.
* Le rationale de Mir est bourré d'inepties et de conneries sur Wayland et on se pose légitimement la question de savoir si les développeurs de Mir ont les compétences pour développer un tel projet.
* Techniquement parlant, Mir est une blague (sinistre)
Ici Canonical n'a même pas l'excuse du "méchant Red Hat qui bloque toutes nos contributions par mesquinerie". Mir est non seulement un gâchis, mais il pourrait se révéler néfaste à l'avenir du bureau libre, en brouillant les signaux.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . En réponse au journal Mir, un serveur d'affichage de trop ?. É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: L'excuse semble un peu juste...
Posté par GeneralZod . En réponse au journal Canonical: les fouteurs de merde, le retour. Évalué à 2.
C'était tellement secret que les premières hackfests concernant le design de GNOME Shell se font fait dans les bureaux de Canonical à leur insu !
https://live.gnome.org/UsabilityProject/London2010
https://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . En réponse au journal Mir, un serveur d'affichage de trop ?. É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 …