Bon j'espère vraiment que Mark Shuttleworth va arrêter avec ses visions et projets complètement loufoques et irréalistes car à ce train là Canonical va rattraper Google sur le nombre de projets morts et avortés.
Le soucis étant qu'ils sont très loin de se le permettre autant…
Ils auraient aussi pu éviter de mettre tout Unity à la poubelle si ils n'avaient pas décidé de réinventer la roue avec Mir.
Comme le montre cette vidéo : https://www.youtube.com/watch?v=BrK4c7iFJLs c'est bien possible. Après je ne sais pas si c'est toujours d'actualité ou si c'est juste un workaround du côté de Compiz.
Maintenant effectivement Wayland contrairement à Xorg a cette fonction innée, alors que Xorg n'a jamais été conçu pour ça.
Bon en même temps quand on voit ces vidéos on ne voit pas de différence avec le desktop que l'on a déjà (je sais que c'est le but, mais ce n'est juste pas "impressionnant" pour quelqu'un qui ne décèle pas le travail nécessaire afin d'avoir obtenu ce résultat).
Néanmoins, maintenant il est tout à fait possible de faire un "compositeur en vue fps" comme montré dans l'article sur X.org.
Wayland n'invente rien de ce côté, vu que c'est le compositeur qui fait ce que bon lui semble avec ses fenêtres dans les deux cas. Il donne juste la possibilité de le faire de manière beaucoup plus simple et performante.
Je regrette un peu que la (seule) vidéo de démonstration de cet article ne soit ni récente ni vraiment représentative des capacités et de l'état actuel de Weston/Wayland, donc voici quelques démonstrations plus récentes et montrant des choses plus "utiles" qu'un compositeur en vue FPS :
Moi ce qui m'énerve par dessus tout dans cette histoire c'est plutôt la réaction des responsables politiques et industriels qui jouent les vierges effarouchées bien qu'étant les premiers complices de tout ça. Le cas de l'avion du président bolivien est un bon exemple de leur aplaventrisme envers les US…
Et, comme expliqué précédemment, ce n'est pas faute de tendre la main (tardivement, certes).
Tu devrais lire la mailing list d'Ubuntu au sujet du support des non-Unity histoire de revoir ta définition de "tendre la main".
En résumé ça donne ça :
"Bon ben voilà soit vous acceptez que KDE/XFCE/etc… soit exécuté sur une couche XMir sur Mir avec toute la lenteur, les bugs que ça apporte et le gain non-existent soit démerdez-vous, car nous notre stack Mesa/EGL et les drivers seront patchés uniquement pour Mir et on a aucunement l'intention de supporter Wayland sur Ubuntu."
00:35 daniels: fwiw, i've got a wayland backend for arm hardware which does server-side allocation right now. didn't require one single change to any of the clients, or even compositors. it's all internal to the egl stack.
Donc non.
Et puis Mir fragmente tout l'écosystème (toolkits, compositors, drivers…), pas seulement quelques "implémentations", tout ça pour aucune raison technique valable mis à part le contrôle complet du stack…
C'est pas faux. Malheureusement c'est pas "l'ensemble de la communauté Ubuntu" qui prend les décisions à propos de Mir ou des relations avec l'upstream/Wayland…
Pourquoi pas ? Où est le problème à ce qu'une application crée son propre buffer graphique et dessine sa fenêtre tout seule comme une grande puis passe le pointer au Compositor ?
L'un des soucis majeurs de l'allocation côté serveur c'est le nombre de roundtrips inutiles client-serveur vu que l'application doit sans cesse demander un nouveau buffer de telle taille au serveur. Je te laisse imaginer le nombre d'IPCs à chaque redimensionnement de fenêtre en plus du fait que le client doit toujours attendre la réponse du server avant de pouvoir dessiner. Un problème autre que la lenteur c'est que X ne peut jamais savoir quelle taille la fenêtre du client sera à t+1, et devra attendre la requête du client pour le savoir, et le temps que le client obtienne son buffer il est souvent déjà invalidé. C'est la source des soucis de corruption/clignotement dans les fenêtres lors de redimensionnements par exemple…
En résumé ça fait 30 ans que les devs X se pètent les dents là dessus; Windows et OSX ayant définitivement enterré l'idée y'a très longtemps aussi. Ça avait peut être du sens quand X se chargeait lui-même de dessiner les fenêtres, mais maintenant à part les rares applis en Motif et xterm toutes les applis/toolkits font leur rendu localement. X est aussi sur cette voie vu que DRI2 autorise déjà partiellement le client-side allocation. DRI3000 va plus loin dans ce sens en étant full client-side ( http://keithp.com/blogs/dri3k_first_steps/ ).
Après, le client-side à ses défauts aussi comme un moindre contrôle sur les buffers (genre on peut plus désallouer aussi facilement un buffer pour une appli qui est minimisée pour libérer de la mémoire) et donc une consommation en RAM plus conséquente, ce qui peut être une contrainte sur les mobiles/tablettes. C'est la justification de Canonical en tout cas, bien que à mon avis fallacieuse vu que Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side), et que la quantité de RAM des mobiles ne cesse d'augmenter…
Wayland n'apporte quasiment pas de progrès au niveau de la composition 3D
Oh que si, et énormément. Le compositing sous X est probablement l'une des pires choses qui soit.
Tu n'imagines même pas le nombre de roundtrips et context switches à la con il faut just pour redimensionner une fenêtre sous X. Car depuis l'avènement des Compositeurs, et le fait que de plus en plus de fonctions de X sont déléguées au Compositeur ou vers le noyau (KMS, evdev…), X ne sert quasiment plus à rien et n'est qu'un boulet inutile entre le Compositeur et les applications. Sous Wayland, le Compositeur gère directement les fenêtres et le GPU sans intermédiaire inutile ce qui fait gagner un temps fou et évite les copies inutiles.
Je te conseille de voir cette excellente conférence de Daniel Stone pour vraiment te rendre compte à quel point X est complètement obsolète et surtout du temps de la Composition notamment : http://www.youtube.com/watch?v=RIctzAQOe44
C'est assez marrant sachant que Mir reprend entre autres l'une des plus grosses tares de X qui est l'allocation des buffers côté serveur. Je n'arrive pas à retrouver le lien d'un dev Xorg qui en parle justement…
D'après ce que j'ai pu comprendre, XWayland est plus performant que X car les applications sont exécutées séparément et en "rootless". En gros chaque application est en fullscreen sur son propre X server ce qui évite pas mal de choses inutiles do coté X comme le Compositing et le fait de gérer plusieurs clients en même temps vu que c'est le Compositeur Wayland qui fera ça.
XMir par contre lance des bureaux entiers sur un seul X server, puis transmet l'image finale à Mir, ce qui en plus de n'éliminer aucun des inconvénients de Xorg (notamment le gros du Compositing fait du côté de X et non de Mir) ne fait que rajouter une couche inutile à l'ensemble.
Si encore Mir :
- A des gros avantages techniques comparé à Wayland,
- Est plus avancé que Wayland en terme de développement,
- Est vraiment libre (pas de CLA),
- Est vraiment indépendant par rapport à la distro et au gestionnaire de fenêtres,
Alors il n'y aurait pas de raison à être contre…
Le soucis c'est qu'il n'y a rien de tout ça pour le moment.
Le concept de Mir rappelle beaucoup celui de Wayland, d'ailleurs leur XMir est un fork de XWayland. D'ailleurs, mis à part ce dernier il y a pas grand chose qui fonctionne, aucun toolkit qui le supporte ou ne prévoit de, on en est encore aux balbutiements, et leur documentation ne présage rien de "révolutionnaire".
De plus connaissant Canonical, il ne serait guère surprenant de voir que ce projet ne soit taillé que pour Ubuntu/Unity. Ce n'est pas la première fois qu'ils réinventent la roue juste pour leur propre intérêt. (upstart, launchpad…)
Donc c'est très inquiétant… Non seulement car cela signifie encore plus de fragmentation, de toolkits/drivers à (re)porter mais en plus sape les efforts de Wayland qui commençait enfin à trouver des oreilles attentives…
En fait ce n'est pas tout à fait correct. KMS n'est pas strictement obligatoire pour Wayland, en fait d'après Kristian lui-même :
According to Kristian closed drivers need 2 things:
A way to set the graphics mode (like KMS, but it could also be a standalone library)
A way to share video memory buffers (for example an EGLImage) between processes
Donc théoriquement les drivers propriétaires peuvent utiliser Wayland sans forcément utiliser KMS/GEM si ils implémentent des mécanismes similaires pour partager les buffers entre les clients et un modesetting noyau.
Pourquoi ? Elle est pertinente quoiqu'il arrive. Tu es en train de me dire qu'un utilisateur qui n'a pas les capacités de contribuer n'a d'autre choix que de fermer sa gueule. Et bien oui, s'il n'a pas de solution à proposer.
Vous savez, il y a d'autres moyens de contribuer à un projet que de pondre du code ou donner : Tester, suggérer (poliment), remonter les bugs, traduire…
Il ne faut pas oublier que à moins qu'un logiciel soit fait pour une niche, la cible principale de la plupart des logiciels sont ces "simples utilisateurs", donc leur retour d'un point de vue utilisateur doit être quand même primordial pour les développeurs… Ça se saurait si tous les utilisateurs d'ordinateurs au monde étaient des développeurs avertis.
Je ne vois pas en quoi c'est un problème. Des devs bénévoles ne sont pas là pour répondre aux besoins de tout le monde. Ils écrivent du code pour répondre à un besoin particulier et le distribuent pour que des gens qui ont le même besoin qu'eux puissent en profiter.
Comme c'est le cas que des utilisateurs prennent le temps de tester des logiciels (sans garantie hein), remontent les bugs et font des suggestions pertinentes afin que ces développeurs améliorent les dits logiciels. En plus de faire connaître ces logiciels à plus de monde (donc plus de retours, de nouveaux contributeurs etc…).
Je vois pas pourquoi opposer les développeurs et donateurs/sponsors aux utilisateurs vu que les uns dépendent des autres et vice-versa.
À vous entendre on croirait que tous ces utilisateurs qui codent pas sont forcément des trolls sans vergogne qui en ont rien à foutre des développeurs. Je dis pas que les trolls n'existent pas, mais c'est pas une raison de mettre tout le monde dans le même panier.
Mais justement si Debian passait à systemd cela signifierait plus (+) de boulot pour les devs ubuntu pour se passer du tentaculaire systemd et mettre leur solution maison à la place en plus du discrédit de celle-ci (la distro mère préfère utiliser une solution concurrente plutôt que celle de sa fille).
Donc je vois plutôt des conséquences "politiques" sur la distribution mère en gros.
Sachant l'immense popularité d'Ubuntu et le fait qu'ils en profitent indirectement, ils pourraient avoir des réticences vis à vis de systemd à cause des choix de cette dernière.
Vu que le poulain de Debian (Ubuntu) est à fond sur upstart et qu'il semblerait qu'ils n'ont nullement l'intention de considérer systemd (http://www.markshuttleworth.com/archives/1121) je doute vraiment que cela arrive (à court terme en tout cas).
Cela fait une bonne année que je l'utilise et j'ai jamais eu aucun soucis.
La gestion des services et de leurs dépendances est enfantine, le démarrage est plus que rapide, la gestion des ressources est vraiment optimisée (services à la demande) etc…..
Techniquement (en tout cas pour moi) systemd n'a aucun égal dans le monde GNU/Linux et sysvinit paraît vraiment archaïque à côté…
…Cependant, c'est compréhensible que la tendance tentaculaire et poussive de systemd risque de provoquer pas mal de remous et certains choix (logs binaires) sont pas du goût de tout le monde (bien qu'il est tout à fait possible d'utiliser un logger traditionnel). La transition aurait pû être plus douce et moins invasive pour les autres distributions qui ne sont pas forcément intéressées pour le moment, mais le fait est que systemd tisse de plus en plus de liens qui font qu'il deviendra quasi inévitable pour tous. Un récent exemple étant le merge d'udev dans systemd, et bien que je sois vraiment satisfait de systemd je n'aime pas ça non plus car on devrait toujours avoir le choix sur GNU/Linux…
Mais bon certains diraient que c'est un mal nécessaire car il est vrai que sysvinit a fait son temps et que la nostalgie n'a pas souvent que du bon pour l'évolution…
Posté par Scias .
En réponse à la dépêche FFmpeg 1.0.
Évalué à 4.
Erreur de ma part après avoir fait un tour sur le site de libav, il semblerait en effet qu'ils avaient un binaire ffmpeg et ce message vient de celui-ci…
Mais la confusion est toujours là en tout cas.
Posté par Scias .
En réponse à la dépêche FFmpeg 1.0.
Évalué à 1.
Ça se comprendrait si ce message venait d'un binaire "ffmpeg" fourni par libav pour raisons de compatibilité, mais il vient du binaire du paquet ffmpeg original.
Ces lignes ont été insérées par l'un des mainteneurs des dépôts de Debian, qui semble-il fait partie ou est proche de cette équipe libav et semble-il espère rallier plus de monde à la cause de libav en déclarant ffmpeg comme mort…
Bref c'est vraiment pathétique (moi qui pensait que les packagers devaient rester neutres?) et tout ça pour de la politique à deux sous.
D'accord c'est pas libre, ni exempt de bugs, et parfois peu intégré (Mono) mais au moins ça a le mérite de nous apporter quelques bons jeux dont la plupart natifs sur notre plateforme préférée.
Donc en plus de populariser Linux auprès du grand public et des développeurs indépendants qui participent au bundles ça prouve qu'il y a un marché possible sous Linux concernant les Jeux.
Sinon sur ce bundle en particulier j'ai rien à redire. Les jeux sont très corrects surtout Torchlight bien que ça n'égale pas la qualité du Bundle V.
Tous natifs à l'exception de Rochard (Unity3D/Mono) qui marche très bien quand même.
Il y a quelques bugs évidemment, ce qui est normal vu que les versions Linux sont des 1.0.0.0, mais aucun qui soit handicapant à ce point.
J'ai été aussi impressionné que tous les jeux fonctionnent "out-of-the-box" sur mon Arch 64-bit (+ Nvidia/blob), pour une fois que j'ai pas eu à traquer les dépendances non-fournies/spécifiées de chaque jeu avec ldd avant de pouvoir jouer…
Bref, tout bénef pour moi.
Donc oui merci à ces développeurs qui ont fait l'effort d'adapter leurs jeux sur Linux et à HiB pour les super bundles !
[^] # Re: Bon choix
Posté par Scias . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à -3.
Bon j'espère vraiment que Mark Shuttleworth va arrêter avec ses visions et projets complètement loufoques et irréalistes car à ce train là Canonical va rattraper Google sur le nombre de projets morts et avortés.
Le soucis étant qu'ils sont très loin de se le permettre autant…
Ils auraient aussi pu éviter de mettre tout Unity à la poubelle si ils n'avaient pas décidé de réinventer la roue avec Mir.
[^] # Re: Capture d'ecran sous linux ?
Posté par Scias . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 7.
Par contre c'est à chier si vous utilisez un thème de bureau sombre et qu'en plus vous utilisez KDE…
[^] # Re: Quelques vidéos plus pertinentes
Posté par Scias . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 4.
Comme le montre cette vidéo : https://www.youtube.com/watch?v=BrK4c7iFJLs c'est bien possible. Après je ne sais pas si c'est toujours d'actualité ou si c'est juste un workaround du côté de Compiz.
Maintenant effectivement Wayland contrairement à Xorg a cette fonction innée, alors que Xorg n'a jamais été conçu pour ça.
[^] # Re: Quelques vidéos plus pertinentes
Posté par Scias . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 1.
Néanmoins, maintenant il est tout à fait possible de faire un "compositeur en vue fps" comme montré dans l'article sur X.org.
Wayland n'invente rien de ce côté, vu que c'est le compositeur qui fait ce que bon lui semble avec ses fenêtres dans les deux cas. Il donne juste la possibilité de le faire de manière beaucoup plus simple et performante.
# Quelques vidéos plus pertinentes
Posté par Scias . En réponse à la dépêche Wayland et Weston 1.4. Évalué à 10.
Je regrette un peu que la (seule) vidéo de démonstration de cet article ne soit ni récente ni vraiment représentative des capacités et de l'état actuel de Weston/Wayland, donc voici quelques démonstrations plus récentes et montrant des choses plus "utiles" qu'un compositeur en vue FPS :
Orbital shell (un plugin pour Weston) : http://www.youtube.com/watch?v=bd1hguj2bPE
Kwin en tant que client sous Weston : http://www.youtube.com/watch?v=-V8i8zZPzbU
Chromium sous Wayland : http://www.youtube.com/watch?v=EJB2pznc6iY
Hawaii Desktop : http://www.youtube.com/watch?v=8_pR9FDDnjw
Weston/Wayland vs X.org sur Raspberry Pi : http://www.youtube.com/watch?v=0UkUal_hHx8
Dolphin-emu (émulateur Gamecube/Wii) : http://www.youtube.com/watch?v=3ZdXu1VM_VQ
…
Donc voilà pour les curieux. On peut quand même constater qu'il ne manque plus grand chose pour que Wayland ne devienne l'alternative qu'il nous faut.
[^] # Re: Manque le choix : je ne suis pas étonné
Posté par Scias . En réponse au sondage Les révélations sur le programme PRISM.... Évalué à 10.
Moi ce qui m'énerve par dessus tout dans cette histoire c'est plutôt la réaction des responsables politiques et industriels qui jouent les vierges effarouchées bien qu'étant les premiers complices de tout ça. Le cas de l'avion du président bolivien est un bon exemple de leur aplaventrisme envers les US…
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 3.
Tu devrais lire la mailing list d'Ubuntu au sujet du support des non-Unity histoire de revoir ta définition de "tendre la main".
En résumé ça donne ça :
"Bon ben voilà soit vous acceptez que KDE/XFCE/etc… soit exécuté sur une couche XMir sur Mir avec toute la lenteur, les bugs que ça apporte et le gain non-existent soit démerdez-vous, car nous notre stack Mesa/EGL et les drivers seront patchés uniquement pour Mir et on a aucunement l'intention de supporter Wayland sur Ubuntu."
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 7. Dernière modification le 20 juillet 2013 à 11:53.
Donc non.
Et puis Mir fragmente tout l'écosystème (toolkits, compositors, drivers…), pas seulement quelques "implémentations", tout ça pour aucune raison technique valable mis à part le contrôle complet du stack…
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 5. Dernière modification le 20 juillet 2013 à 10:31.
C'est pas faux. Malheureusement c'est pas "l'ensemble de la communauté Ubuntu" qui prend les décisions à propos de Mir ou des relations avec l'upstream/Wayland…
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 6.
Pourquoi pas ? Où est le problème à ce qu'une application crée son propre buffer graphique et dessine sa fenêtre tout seule comme une grande puis passe le pointer au Compositor ?
L'un des soucis majeurs de l'allocation côté serveur c'est le nombre de roundtrips inutiles client-serveur vu que l'application doit sans cesse demander un nouveau buffer de telle taille au serveur. Je te laisse imaginer le nombre d'IPCs à chaque redimensionnement de fenêtre en plus du fait que le client doit toujours attendre la réponse du server avant de pouvoir dessiner. Un problème autre que la lenteur c'est que X ne peut jamais savoir quelle taille la fenêtre du client sera à t+1, et devra attendre la requête du client pour le savoir, et le temps que le client obtienne son buffer il est souvent déjà invalidé. C'est la source des soucis de corruption/clignotement dans les fenêtres lors de redimensionnements par exemple…
En résumé ça fait 30 ans que les devs X se pètent les dents là dessus; Windows et OSX ayant définitivement enterré l'idée y'a très longtemps aussi. Ça avait peut être du sens quand X se chargeait lui-même de dessiner les fenêtres, mais maintenant à part les rares applis en Motif et xterm toutes les applis/toolkits font leur rendu localement. X est aussi sur cette voie vu que DRI2 autorise déjà partiellement le client-side allocation. DRI3000 va plus loin dans ce sens en étant full client-side ( http://keithp.com/blogs/dri3k_first_steps/ ).
Après, le client-side à ses défauts aussi comme un moindre contrôle sur les buffers (genre on peut plus désallouer aussi facilement un buffer pour une appli qui est minimisée pour libérer de la mémoire) et donc une consommation en RAM plus conséquente, ce qui peut être une contrainte sur les mobiles/tablettes. C'est la justification de Canonical en tout cas, bien que à mon avis fallacieuse vu que Wayland ne force pas l'allocation client (y'avait même un Weston expérimental en server-side), et que la quantité de RAM des mobiles ne cesse d'augmenter…
Maintenant Mir heureusement fait les choses un peu différemment de X et évite quelques allers-retours inutiles ( http://blog.cooperteam.net/2013/03/server-allocated-buffers-in-mir.html ), mais techniquement il y aura toujours un avantage au client-side niveau vitesse en tout cas.
[^] # Re: Et compiz ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 9.
Oh que si, et énormément. Le compositing sous X est probablement l'une des pires choses qui soit.
Tu n'imagines même pas le nombre de roundtrips et context switches à la con il faut just pour redimensionner une fenêtre sous X. Car depuis l'avènement des Compositeurs, et le fait que de plus en plus de fonctions de X sont déléguées au Compositeur ou vers le noyau (KMS, evdev…), X ne sert quasiment plus à rien et n'est qu'un boulet inutile entre le Compositeur et les applications. Sous Wayland, le Compositeur gère directement les fenêtres et le GPU sans intermédiaire inutile ce qui fait gagner un temps fou et évite les copies inutiles.
Je te conseille de voir cette excellente conférence de Daniel Stone pour vraiment te rendre compte à quel point X est complètement obsolète et surtout du temps de la Composition notamment : http://www.youtube.com/watch?v=RIctzAQOe44
[^] # Re: Waylands et Mir ?
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 2.
Tu disais ?
C'est assez marrant sachant que Mir reprend entre autres l'une des plus grosses tares de X qui est l'allocation des buffers côté serveur. Je n'arrive pas à retrouver le lien d'un dev Xorg qui en parle justement…
[^] # Re: Changement de pilote
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland ! (3). Évalué à 10.
D'après ce que j'ai pu comprendre, XWayland est plus performant que X car les applications sont exécutées séparément et en "rootless". En gros chaque application est en fullscreen sur son propre X server ce qui évite pas mal de choses inutiles do coté X comme le Compositing et le fait de gérer plusieurs clients en même temps vu que c'est le Compositeur Wayland qui fera ça.
XMir par contre lance des bureaux entiers sur un seul X server, puis transmet l'image finale à Mir, ce qui en plus de n'éliminer aucun des inconvénients de Xorg (notamment le gros du Compositing fait du côté de X et non de Mir) ne fait que rajouter une couche inutile à l'ensemble.
# Pourquoi pas ? Mais...
Posté par Scias . En réponse à la dépêche Mir, un serveur d’affichage de trop ?. Évalué à 5.
Si encore Mir :
- A des gros avantages techniques comparé à Wayland,
- Est plus avancé que Wayland en terme de développement,
- Est vraiment libre (pas de CLA),
- Est vraiment indépendant par rapport à la distro et au gestionnaire de fenêtres,
Alors il n'y aurait pas de raison à être contre…
Le soucis c'est qu'il n'y a rien de tout ça pour le moment.
Le concept de Mir rappelle beaucoup celui de Wayland, d'ailleurs leur XMir est un fork de XWayland. D'ailleurs, mis à part ce dernier il y a pas grand chose qui fonctionne, aucun toolkit qui le supporte ou ne prévoit de, on en est encore aux balbutiements, et leur documentation ne présage rien de "révolutionnaire".
De plus connaissant Canonical, il ne serait guère surprenant de voir que ce projet ne soit taillé que pour Ubuntu/Unity. Ce n'est pas la première fois qu'ils réinventent la roue juste pour leur propre intérêt. (upstart, launchpad…)
Donc c'est très inquiétant… Non seulement car cela signifie encore plus de fragmentation, de toolkits/drivers à (re)porter mais en plus sape les efforts de Wayland qui commençait enfin à trouver des oreilles attentives…
[^] # Re: Pilotes graphiques libres
Posté par Scias . En réponse à la dépêche X.Org est mort, vive Wayland !. Évalué à 10.
En fait ce n'est pas tout à fait correct. KMS n'est pas strictement obligatoire pour Wayland, en fait d'après Kristian lui-même :
Donc théoriquement les drivers propriétaires peuvent utiliser Wayland sans forcément utiliser KMS/GEM si ils implémentent des mécanismes similaires pour partager les buffers entre les clients et un modesetting noyau.
[^] # Re: Parallèle avec dragonfly
Posté par Scias . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 10.
Vous savez, il y a d'autres moyens de contribuer à un projet que de pondre du code ou donner : Tester, suggérer (poliment), remonter les bugs, traduire…
Il ne faut pas oublier que à moins qu'un logiciel soit fait pour une niche, la cible principale de la plupart des logiciels sont ces "simples utilisateurs", donc leur retour d'un point de vue utilisateur doit être quand même primordial pour les développeurs… Ça se saurait si tous les utilisateurs d'ordinateurs au monde étaient des développeurs avertis.
Comme c'est le cas que des utilisateurs prennent le temps de tester des logiciels (sans garantie hein), remontent les bugs et font des suggestions pertinentes afin que ces développeurs améliorent les dits logiciels. En plus de faire connaître ces logiciels à plus de monde (donc plus de retours, de nouveaux contributeurs etc…).
Je vois pas pourquoi opposer les développeurs et donateurs/sponsors aux utilisateurs vu que les uns dépendent des autres et vice-versa.
À vous entendre on croirait que tous ces utilisateurs qui codent pas sont forcément des trolls sans vergogne qui en ont rien à foutre des développeurs. Je dis pas que les trolls n'existent pas, mais c'est pas une raison de mettre tout le monde dans le même panier.
[^] # Re: Debian et systemd
Posté par Scias . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -2. Dernière modification le 14 octobre 2012 à 18:55.
Oui merci je suis d'accord avec ceci.
Mais justement si Debian passait à systemd cela signifierait plus (+) de boulot pour les devs ubuntu pour se passer du tentaculaire systemd et mettre leur solution maison à la place en plus du discrédit de celle-ci (la distro mère préfère utiliser une solution concurrente plutôt que celle de sa fille).
Donc je vois plutôt des conséquences "politiques" sur la distribution mère en gros.
Sachant l'immense popularité d'Ubuntu et le fait qu'ils en profitent indirectement, ils pourraient avoir des réticences vis à vis de systemd à cause des choix de cette dernière.
[^] # Re: Debian et systemd
Posté par Scias . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à -2.
Vu que le poulain de Debian (Ubuntu) est à fond sur upstart et qu'il semblerait qu'ils n'ont nullement l'intention de considérer systemd (http://www.markshuttleworth.com/archives/1121) je doute vraiment que cela arrive (à court terme en tout cas).
# Un mal nécessaire ?
Posté par Scias . En réponse à la dépêche Archlinux utilise désormais systemd par défaut pour les nouvelles installations. Évalué à 10.
Cela fait une bonne année que je l'utilise et j'ai jamais eu aucun soucis.
La gestion des services et de leurs dépendances est enfantine, le démarrage est plus que rapide, la gestion des ressources est vraiment optimisée (services à la demande) etc…..
Techniquement (en tout cas pour moi) systemd n'a aucun égal dans le monde GNU/Linux et sysvinit paraît vraiment archaïque à côté…
…Cependant, c'est compréhensible que la tendance tentaculaire et poussive de systemd risque de provoquer pas mal de remous et certains choix (logs binaires) sont pas du goût de tout le monde (bien qu'il est tout à fait possible d'utiliser un logger traditionnel). La transition aurait pû être plus douce et moins invasive pour les autres distributions qui ne sont pas forcément intéressées pour le moment, mais le fait est que systemd tisse de plus en plus de liens qui font qu'il deviendra quasi inévitable pour tous. Un récent exemple étant le merge d'udev dans systemd, et bien que je sois vraiment satisfait de systemd je n'aime pas ça non plus car on devrait toujours avoir le choix sur GNU/Linux…
Mais bon certains diraient que c'est un mal nécessaire car il est vrai que sysvinit a fait son temps et que la nostalgie n'a pas souvent que du bon pour l'évolution…
[^] # Re: Qui a suivi cette affaire?
Posté par Scias . En réponse à la dépêche FFmpeg 1.0. Évalué à 4.
Erreur de ma part après avoir fait un tour sur le site de libav, il semblerait en effet qu'ils avaient un binaire ffmpeg et ce message vient de celui-ci…
Mais la confusion est toujours là en tout cas.
[^] # Re: Qui a suivi cette affaire?
Posté par Scias . En réponse à la dépêche FFmpeg 1.0. Évalué à 1.
Ça se comprendrait si ce message venait d'un binaire "ffmpeg" fourni par libav pour raisons de compatibilité, mais il vient du binaire du paquet ffmpeg original.
Ces lignes ont été insérées par l'un des mainteneurs des dépôts de Debian, qui semble-il fait partie ou est proche de cette équipe libav et semble-il espère rallier plus de monde à la cause de libav en déclarant ffmpeg comme mort…
Bref c'est vraiment pathétique (moi qui pensait que les packagers devaient rester neutres?) et tout ça pour de la politique à deux sous.
[^] # Re: Et un ptit "merci" en plus
Posté par Scias . En réponse à la dépêche Humble Indie Bundle 6. Évalué à 5.
+1
D'accord c'est pas libre, ni exempt de bugs, et parfois peu intégré (Mono) mais au moins ça a le mérite de nous apporter quelques bons jeux dont la plupart natifs sur notre plateforme préférée.
Donc en plus de populariser Linux auprès du grand public et des développeurs indépendants qui participent au bundles ça prouve qu'il y a un marché possible sous Linux concernant les Jeux.
Sinon sur ce bundle en particulier j'ai rien à redire. Les jeux sont très corrects surtout Torchlight bien que ça n'égale pas la qualité du Bundle V.
Tous natifs à l'exception de Rochard (Unity3D/Mono) qui marche très bien quand même.
Il y a quelques bugs évidemment, ce qui est normal vu que les versions Linux sont des 1.0.0.0, mais aucun qui soit handicapant à ce point.
J'ai été aussi impressionné que tous les jeux fonctionnent "out-of-the-box" sur mon Arch 64-bit (+ Nvidia/blob), pour une fois que j'ai pas eu à traquer les dépendances non-fournies/spécifiées de chaque jeu avec ldd avant de pouvoir jouer…
Bref, tout bénef pour moi.
Donc oui merci à ces développeurs qui ont fait l'effort d'adapter leurs jeux sur Linux et à HiB pour les super bundles !