Journal XFree86 perds des kilos

Posté par .
Tags : aucun
0
3
août
2004
Avec l'été, beaucoup de gens cherchent *le* régime efficace. Ne chercher plus, on l'a découvert pour vous ! Ce regime est miraculeux et a permi à la page des systèmes d'exploitation supportant XFree86 [1] de bien maigrir. FreeBSD s'est retiré récemment et plus le temps passe, moins il y a de système utilisant XFree86. Il ne leur reste aucun grand nom si ce n'est NetBSD.

D'ici à ce que X.Org commence à vraiment être différent de XFree86 au niveau des modules & technologies proposés, beaucoup de distribution devront faire un choix : passer à X.Org et utiliser un logiciel au développement plus actif, beaucoup plus à jour et mieux reconnu (FreeDesktop & distributions majeures) ou rester avec XFree86 et risquer de rencontrer des limitations avec certaines applications, voire des disfonctionnements.

J'en connais au moins un qui doit se mordre les doigts jusqu'à l'os ...

[1] http://www.xfree86.org/distros(...)
  • # xorg est aussi dispo pour netbsd

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

    Il n'est pas encore utilisé pas la base de netbsd (mais que nous réserve netbsd 2.0 ?)
    Par contre, il est arrivé dans pkgsrc (le gestionnaire de packages de netbsd) eux alentours du 29 juillet, avec son imake, les clients, et tout.
    Du coup, les packages de pkgsrc peuvent etre compilés pour tourner avec le x de xorg, et ça donnes un coup de jeune a netbsd.

    D'ailleurs, merci xtraeme pour avoir fait ce boulot d'intégration

    A noter que ça rend facile de recompiler xorg sous d'autres architectures, puisque les paquets pkgsrc xorg semblent compiler sans problèmes sous linux et openbsd aussi, et probablement fonctionnent bien ailleurs
  • # ati, nvidia et autre

    Posté par . Évalué à 4.

    Reste à voir si les constructeurs de cartes graphiques suiveront et fourniront des drivers pour Xorg ou leur spéc.

    Si certaines cartes ne sont utilisables qu'en 2D sur Xorg, cela risque de ralentir sa progression au profit de Xfree.
    • [^] # Re: ati, nvidia et autre

      Posté par . Évalué à 5.

      C'est vraiment un point auquel je n'avais pas pensé :o Quelqu'un aurait des informations sur le support de X.Org par les constructeurs de cartes graphiques ? Voire mieux : est-ce que qu'il y en a pour lequels les pilotes de leur carte graphique 3D existent pour XFree86 mais ne fonctonnent déjà pas avec X.Org ?

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: ati, nvidia et autre

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

        ati et nvidia supportent déjà xorg. Il y a même un de ces deux drivers, je ne sais plus lequel, qui ne fonctionne pas avec XFree 4.4.0 mais marche sous Xorg.
  • # C'est fini...

    Posté par . Évalué à 7.

    Il faut se rendre à l'évidence, XFree86 c'est fini.

    Ce n'est qu'une question de temps avant que les distributions restantes (qui toutes cummulées ne doivent pas dépasser les 5%) passent à Xorg. Aucune de ces distributions ne peut se permettre d'être potentiellement incompatible avec les poids lourds que sont RedHat, Mandrake, Suse etc...

    De ce fait, je pense que les constructeurs suivront Xorg pour leurs prochains pilotes si il y avait incompatibilité.

    Voilà un changement de licence qui a fait des dégats. Cela montre bien la capacité de réaction (de forkage ?) du monde OpenSource.
    • [^] # Re: C'est fini...

      Posté par . Évalué à 5.

      Reste à savoir si le fork depassera l'original ...
      Jusqu'a maintenant, je n'ai jamais vraiment vu de fork aussi puissant que XFree86; xorg sortirait t'il du lot ?

      Mais seul le temps nous le dira.
    • [^] # Re: C'est fini...

      Posté par . Évalué à 4.

      Je ne pense pas qu'être "compatible" avec certaines distributions soit vraiment un arguement qui a fait changer d'avis les mainteneurs de distributions (Notamment FreeBSD..).

      Je pense plutôt qu'une alternative active est née dans Xorg et que celui de XFree stagne depuis longtemps.. Il n'y a donc pas photo.. La sanction est souvent vite faite lorsqu'un logiciel est mis face à un concurrent qui présente plus d'avantages.
  • # X.org ce n'est pas encore la panacée

    Posté par . Évalué à 0.

    C'est pas dur, sur ma Cooker, avec le passage à X.org, toute l'interfaçe semble être ralentie. D'ailleurs, ma konsole à fond transparent que je pouvais déplacer d'une manière fluide auparavant (excepté après un arrêt temporaire, auquel cas l'image de fond en fausse transparence était recalculée) ne se déplace désormais qu'à grandes saccades (le temps de recalculer l'image à placer en fausse transparence).

    Bref, c'est bien gentil X.org, mais tout ça cumulé avec de nombreux bogues que j'ai rencontré sur Cooker (écrasement du fichier de configuration, perte de la transparence du fond des icônes dans kicker, etc.) me fait dire qu'il va falloir bosser pas mal.

    En attendant, l'interfaçe de ma Cooker, à configuration équivalente (matérielle et logicielle), est bien moins réactive que celle de ma Mandrake 10.0 officielle, qui elle est encore sous XFree86 !
    • [^] # Re: X.org ce n'est pas encore la panacée

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

      c'est pas la faute à Xorg si cooker pue..
    • [^] # Re: X.org ce n'est pas encore la panacée

      Posté par . Évalué à 10.

      C'est pas plutôt tout simplement que les paquets KDE sont compilés avec les informations de débogage ?
      • [^] # Re: X.org ce n'est pas encore la panacée

        Posté par . Évalué à -2.

        Les infos de débogage ne ralentissent pas mais bon...
        • [^] # Re: X.org ce n'est pas encore la panacée

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

          Les infos de débogage ne ralentissent pas mais bon...

          ... mais bon, si tes executables prennent du poids, tu augmentes automatiquement la chance que ta memoire sature, donc que tu swap, donc que cela entraine la chutte des perfs de ta machine, mais bon ...
          • [^] # Re: X.org ce n'est pas encore la panacée

            Posté par . Évalué à 3.

            Non plus... les symboles de debug sont pas chargés en mémoire.
            • [^] # Re: X.org ce n'est pas encore la panacée

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

              Non plus... les symboles de debug sont pas chargés en mémoire.

              Ah bon ? T'es sur de ce que tu dis ? Cela m'etonne beaucoup. Par exemple lorsque tu lances :
              gdb < ton_binaire_non_strippé >

              Les symboles ne sont pas chargés en memoire ?????? Ils restent sur le disque ???? J'aimerai beaucoup une preuve de ce que tu avances !
              • [^] # Re: X.org ce n'est pas encore la panacée

                Posté par . Évalué à 4.

                C'est le débuggage qui bouffe de la RAM, pas les infos de debuggage en elle même.

                Si tu ne passe pas par gdb ca ne ralenti donc pas

                Et j'aimerais bien savoir pourquoi on se fait moinsser simplement quand on dit des trucs verifiablement vrai.
                • [^] # Re: X.org ce n'est pas encore la panacée

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

                  > C'est le débuggage qui bouffe de la RAM, pas les infos de debuggage en elle même.
                  >
                  > Si tu ne passe pas par gdb ca ne ralenti donc pas

                  Ben si tu as des infos de debuggage, meme si ca prend pas bcp de RAM, ca en prend quand meme...

                  > Et j'aimerais bien savoir pourquoi on se fait moinsser simplement quand on dit des trucs verifiablement vrai.

                  Personellement, je ne t'ai pas moinsé, mais ceux qui l'ont fait ont peut etre trouvé ton post un peu rapide et sans argument ?
  • # passer la tondeuse

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

    C'est typiquement le genre de commentaires qui ont poussé les dév de X à changer de licence :

    http://www.xfree86.org/legal/licenses.html(...)

    He noted that the main reason was to ensure that the Project and its developers receive their full due for what they have given freely away these past 12 years.

    J'en connais au moins un qui doit se mordre les doigts jusqu'à l'os ...

    J'ai l'impression que ça te fait presque plaisir, explique moi pourquoi.
    Ces dernières années, sans le projet xfree, on aurait été bien malheureux sur nos pingouins.
    • [^] # Re: passer la tondeuse

      Posté par . Évalué à 2.

      > J'ai l'impression que ça te fait presque plaisir, explique moi pourquoi.

      Moi, ça me fait plaisir.
      XFree86 a choppé le melon et ils pensaient qu'ils étaient le nombril du monde, qu'ils pouvaient changer de licence, ignorer les "coup de semonce" sur leur "modèle" de développement, etc...

      La réussite de XOrg montre qu'ils ne sont pas le nombril du monde et qu'on peut faire sans eux. C'est une force du logiciel libre.
      • [^] # Re: passer la tondeuse

        Posté par . Évalué à 3.

        > XFree86 a choppé le melon

        Par "XFree86" je ne parle pas de tous les développeurs. Je parle du "directoir".
        La majorité des anciens développeurs/contributeurs d'XFree86 bosse maintenant sur X.Org.
    • [^] # Re: passer la tondeuse

      Posté par . Évalué à 5.

      s/les dev/le mainteneur/

      Tous le monde était de loin pas d'accord ( d'ou le fork ... )
  • # X11 doit-il mourir ?

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

    Puisque XFree86 est mort, j'espère que X.org saura faire évoluer X11 dans le bon sens, car il en a besoin le bougre ! Car d'après Marks Thomas du projet Y Windows, X11 a pas mal de points noirs. Je suis tout à fait d'accord avec lui.

    - X11est trop lent. Les temps de latences sont trop elevés. Ca rame et ça saute aux yeux.

    - La Xlib est obsolète et trop difficile à utiliser, les programmeurs s'orientent donc vers un autre toolkit. Quel intérêt d'avoir une Xlib si personne l'utilise ?

    - X11 n'a pas de toolkit en standard, pas moyen de construire une application graphique, il manque trop de composants.

    - X11 arrive en fin de vie. Les maintes modifications et extensions faites en dix ans font de X11 un désordre incohérent. Certaines nouvelles extensions interférent avec d'autres plus anciennes.

    - X11 est trop complex. Le protocole X est lui même trop complexe et le protocole ICCCM, une couche supplémentaire censée résoudre des problèmes en crée d'autres. D'ailleurs des bureaux comme KDE ou GNOME ont préférés réimplémenter leur propre protocole (DCOP et CORBA).

    - Les fenêtres ne sont pas bufférisées. Toutes les opérations se font directement à l'écran. Pareil pour le clipping, qui peut prendre un temps monstrueux pour des formes complexes. L'application qui possède la fenêtre doit être contacté pour retracer le contenu. Bon résultat ça clignote de partout, l'impression donnée n'est pas professionnelle, et pas très jolie.

    Enfin les deux seuls avantages de X11 aujourd'hui sont sa transprence réseau et sa modularité. Je rajouterai la disponibilité de pilotes et sa large diffusion.
    • [^] # Re: X11 doit-il mourir ?

      Posté par . Évalué à 2.

      Le Monsieur du projet Y a tout intérêt à critiquer X.

      Tout le reste, c'est du troll. C'est pas faux (quoique... Les fenêtres sont bufferisées par exemple (dépend du serveur)), mais c'est du troll.
    • [^] # Re: X11 doit-il mourir ?

      Posté par . Évalué à 5.

      Prenons alors le couple Y/Y Windows qui est, parait-il (je ne suis pas tout à fait d'accord...), la meilleur alternative à X11/Xorg.

      Combien de temps faudrait il pour que le projet arrive à maturité ? Ensuite, combien de temps pour que les applications soient portées ? Dans ce cas, il ne faut pas porter le toolkit, ce qui serait finalement assez rapide, mais toutes les applications puisque Y intègre les toolkits. Et pour finir, combien de temps pour avoir des pilotes ?

      Je suis vraiment partisan de faire évoluer le système graphique de Linux/BSD/... car il est clair que l'Open Source a un sacré retard dans ce domaine. Je sais que certain diront : "la transparence cestnulçasertarien blablabla".

      N'empeche que même si ça ne sert à rien, il faut vivre avec son temps et pour conquérir des utilisateurs, les gadgets user-friendly, ça en met plein la vue. Si toutes les distributions pouvaient se vanter de faire la même chose que ce que l'on voit sur les captures de DirectFB [1], ça en calmerait beaucoup et je suis sur que l'on gagnerais beaucoup d'utilisateurs.

      [1] http://www.directfb.org/screenshots/index.xml(...)
    • [^] # Re: X11 doit-il mourir ?

      Posté par . Évalué à 10.

      > - X11est trop lent. Les temps de latences sont trop elevés. Ca rame et ça saute aux yeux.

      Je possède une bonne vieille Mach64 bien configurée par mes soins sur une modeste machine et je ne constate aucun "temps de latence élevés". Je ne suis pas un gamer, c'est peut être pour ça. J'adore les gestionnaire de fenêtre léger (XFWM4/IceWM) et le bureau XFCE4, c'est aussi peut être pour ça.

      > X11 est trop complex. Le protocole X est lui même trop complexe et le protocole ICCCM, une couche supplémentaire censée résoudre des problèmes en crée d'autres. D'ailleurs des bureaux comme KDE ou GNOME ont préférés réimplémenter leur propre protocole (DCOP et CORBA).

      Le protocole X est un protocole de communication client/serveur. ICCCM [1] n'est pas un protocole mais un ensemble de convention. Donc ICCCM n'a rien à voir avec le protocole X est n'est pas une couche supplémentaire à X. ICCCM est un ensemble de convention pour permettre auc différents clients d'un serveur X de se comporter selon des règles communes.

      DCOP et CORBA n'ont rien à voir avec tout ça. Si tu fesais référence à ICCCM, ce qu'ont permis GNOME et KDE, ce sont des extension à ICCCM appelées EWMH [2].

      [1] ICCCM : http://tronche.com/gui/x/icccm/(...)
      [2] EWMH : http://freedesktop.org/Standards/wm-spec/1.3/(...)

      > Les fenêtres ne sont pas bufférisées.

      http://www.die.net/doc/linux/man/man3/dbe.3.html(...)

      > Toutes les opérations se font directement à l'écran.

      Oui bien sûr, et tu crois aussi que les lecteurs vidéo sous Linux décode les frames d'un DVD/CD/Fichier Vidéo directement en tapant sur ton écran ?

      > L'application qui possède la fenêtre doit être contacté pour retracer le contenu.

      Faux, ce n'est absolument pas une nécessité :
      -> http://tronche.com/gui/x/xlib/window/attributes/backing-store.html(...)

      Bref, je m'arrête là pour la critique de ton message qui contient à l'évidence trop d'incohérences pour être pris au sérieux. Encore du réchaffé de lieux communs sans explications, exemples ou liens étayant une argumentation bien évidemment inexistante.

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: X11 doit-il mourir ?

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

        > -> http://tronche.com/gui/x/xlib/window/attributes/backing-store.html((...))

        oui mais là quand même pas tout à fait:
        - l'extension backingstore est désactivée par défaut, il faut la spécifier dans le XF86Config
        - quand elle est activée, elle marche très mal (X à 100% de cpu, la souris qui n'avance plus) « people who understand X server internals refer to the existing backing store implementation [dans xfree86] as something resembling garbage »
        • [^] # Re: X11 doit-il mourir ?

          Posté par . Évalué à 3.

          À mon avis, ça doit dépendre des pilotes vidéo utilisés. J'utilise personnellement la Backing Store activé (option +bs de X dans mon .xserverrc) sur ma carte graphique ATI XPert@Play 98 (une Mach64) et la différence est notable.

          Par exemple, je lance Nautilus ou Rox et que j'ouvre un dossier avec de nombreux fichiers/dossiers et ensuite je clique droit sur une icône pour demander les propriétés d'un fichier. À ce moment le menu disparaît, et laisse derrière lui une zone blanche visible un court instant avant d'afficher le fenêtre des propriétés du fichier.

          Avant le Backing Store activé, je n'ai pas cette "zone blanche". Normalement, un menu ou une boîte de dialogue ont l'attribut Save Under évite ce genre de désagréement, mais force est de constater que sur ma configuration, cette zone blanche est présente sans le Backing Store et absente avec. De même, le déplacement opaques des fenêtres est plus "net" au niveau des fenêtres invalidées avec le Backing Store.

          Ceci dit, il est vrai que l'utilisation du CPU avec le Backing Store est plus importante lors des opérations graphiques sur la fenêtre mère qui auraient nécessité un redessin de la zone invalidité par une fenêtre fille. Mais bon, je pense que dans un sens c'est normal. Par contre concernant les problèmes de souris ou l'utilisation de 100% du CPU, je n'ai pas remarqué de tel phénomène en regardant ce que ça donne dans un gkrellm lancé pour l'occasion.

          « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

          • [^] # Re: X11 doit-il mourir ?

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

            Rââââaaaaaaaaaa merci ! Quel confort maintenant :)
            Je ne connaissais pas du tout cette option, je viens de tester, ça marche nickel.
            J'ai moi aussi une mach64 (ati rage mobility M1) et j'ai pu constater que cela n'affecte en rien les performances.
            J'ai un duron 1Ghz@500Mhz trop rapide pour mes petits yeux, bouger violemment une fenêtre devant tout un tas de fenêtre ne provoque plus de problèmes d'affichage, le cpu monte à environ 7%, mais je crois que cela le faisait aussi avant).
            J'essayerais ce soir avec les drivers Vesa.
      • [^] # Re: X11 doit-il mourir ?

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

        Tout d'abord je ne suis pas un expert X11, j'ai juste traduit rapidement quelques phrases du document de Marks Thomas.
        http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/Mark(...)

        Ensuite mes essais de programmation de la Xlib m'ont convaincu de la trop grande complexité de cette dernière et de la lenteur de X11. J'avais eu de grands espoirs en XFree86 4.0, mais j'ai vite déchanté.

        >[...] je ne constate aucun "temps de latence élevés". [...] J'adore les gestionnaire de fenêtre léger (XFWM4/IceWM) et le bureau XFCE4, c'est aussi peut être pour ça.
        Que tu sois satisfait de X11 sur ta Mach 64 ne fait pas de X11 un système rapide. Le fait que tu recherches un gestionnaire de fenêtre léger est que peut-être inconsciemment tu te rends compte des limites de X11. Moi aussi je l'utilise tous les jours et m'en contente aussi, car malheureusement aujourd'hui X11 est le seul gestionnaire graphique libre qui permet d'avoir un bureau Linux.Y Windows et DirectFB ne sont pas assez abouti, bien que ce dernier avance à grands pas.

        > Les fenêtres ne sont pas bufférisées.
        >> http://www.die.net/doc/linux/man/man3/dbe.3.html(...)
        Oui c'est bien pour développer un jeu, mais ça rien à voir avec ce que jevoulais dire, c'est à dire le gestionnaire de fenêtre ne bufferise pas les fenêtres.

        > ICCCM est un ensemble de convention pour permettre auc différents clients d'un serveur X de se comporter selon des règles communes.
        Autant pour moi. Enfin il est quand même abhérant que d'un côté X11 est son propre presse papier et que GNOME est aussi le sien.

        >Oui bien sûr, et tu crois aussi que les lecteurs vidéo sous Linux décode les frames d'un DVD/CD/Fichier Vidéo directement en tapant sur ton écran ?
        Très drôle :-) En passant DGA permet de le faire.
        Ce qui signifie que toutes les opérations sont faites, dont le clipping, dans le buffer écran principal (et pas la mémoire vidéo :-)
        Il suffit de supperposer plusieurs fenêtres de les déplacer et de les redimensionner pour voir lé résultat.

        >Faux, ce n'est absolument pas une nécessité :
        Oui je suis d'accord ce n'est pas nécessaire, mais pourtant c'est comme ça que ça fonctionne.

        >argumentation bien évidemment inexistante.
        Une démo vaut mieux qu'un long discours : startx
    • [^] # Re: X11 doit-il mourir ?

      Posté par . Évalué à 2.

      - La Xlib est obsolète et trop difficile à utiliser, les programmeurs s'orientent donc vers un autre toolkit. Quel intérêt d'avoir une Xlib si personne l'utilise ?

      ?????????? Les toolkit sous X sont une couche au dessus de la Xlib

      - X11 n'a pas de toolkit en standard, pas moyen de construire une application graphique, il manque trop de composants.

      C'est pas son role. La xlib fournit les outils qui permettent de construire ton toolkit.

      • [^] # Re: X11 doit-il mourir ?

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

        C'est pas son role. La xlib fournit les outils qui permettent de construire ton toolkit.

        Nuance, ce n'est plus son rôle, car elle a été incapable de le remplir. D'où l'apparition de Motif, QT et GTK. Résultat des couches supplémentaires, qui ralentissent un peu le tout, des applications à l'apparence non homogènes (suivant qu'elles utilisent Motif, QT ou GTK), de la mémoire gaspillée, car une fois instanciée en mémoire ces bilbliothèques occupent un peu plus de quelques octets.

        Sinon je ne suis certain que la Xlib soit adaptée à supporter des toolkits, pour preuve, GTK a remis encore une p'tite couche au dessus de la Xlib : GDK.

        Si X11 avait proposé un bon toolkit dès le début, le bureau Linux ne serait pas si fragmenté aujourd'hui.
        • [^] # Re: X11 doit-il mourir ?

          Posté par . Évalué à 1.

          Pourquoi GTK, QT et Motif utilisent-ils la xlib ? Ils pourraient utiliser directement le protocole X.
          Et cette question en rejoint une autre : pourquoi y'a t'il aussi peu d'implementation de la xlib (Ca me semble plus simple que de faire un serveur X) ?
          • [^] # Re: X11 doit-il mourir ?

            Posté par . Évalué à 2.

            Pourquoi GTK, QT et Motif utilisent-ils la xlib ? Ils pourraient utiliser directement le protocole X.


            Pourquoi Debian, Slackware, Redhat, Suse, utilise-t-ils e noyau Linux? Ils pourraient accéder directement au marériel ...

            C'est peut-être pour ne pas réinventer la roue ....

            pourquoi y'a t'il aussi peu d'implementation de la xlib
            Si on prend l'exemple de GCC, pourquoi n'y a-t-il pas plus d'implémentation de compilateurs C ?

            Peut-être parce que celles qui existent marchent bien, pour ne pas réinventer la roue ....

            D'ailleurs, il existe pas mal d'implémentatuion de la xlib propriétaires (tout comme il existe des compilateurs propriétaires)...
        • [^] # Re: X11 doit-il mourir ?

          Posté par . Évalué à 2.

          > Nuance, ce n'est plus son rôle, car elle a été incapable de le remplir.

          Hum, je croyais que dès le début, le toolkit "de démo" c'était athéna.
        • [^] # Re: X11 doit-il mourir ?

          Posté par . Évalué à 3.

          Nuance, ce n'est plus son rôle, car elle a été incapable de le remplir.

          Il me semble (peut-être à tort) que ca n'a jamais été le role de la xlib de fournir le toolkit, ce qui expliquerait qu'elle n'ait jamais été capable de remplir ce rôle, si j'en crois mes souvenirs et

          http://echo-linux.alienor.fr/articles/xlib/xlib.html#2(...)
          ou http://users.actcom.co.il/~choo/lupg/tutorials/xlib-programming/xli(...)

          http://echo-linux.alienor.fr/articles/xlib/xlib.html#2(...)

          Sinon, si je suis bien ce que tu dis:
          - xlib n'a jamais été capable de fournir un toolkit
          - Des couches supplémentaires ont donc été ajoutées à la xlib
          - tu n'es pas certain que la xlib soit adaptée à supporter des toolkits, pour preuve, GTK a remis encore une p'tite couche au dessus de la Xlib
          - Si X11 avait proposé un bon toolkit dès le début, le bureau Linux ne serait pas si fragmenté aujourd'hui.

          Pour moi ca ne fait que confirmer que la xlib n'est pas un toolkit, mais une bibliothèque d'accès bas niveau au protocole X.

          Le fait que GTK en a rajouté une petite couche au dessus est donc normal, puisque c'est le role de GTK, un toolkit, qui par définition utilise la xlib pour créer ses boutons, menuis, etc....
    • [^] # Re: X11 doit-il mourir ?

      Posté par . Évalué à 3.

      > - X11est trop lent. Les temps de latences sont trop elevés. Ca rame
      > et ça saute aux yeux.
      Je ne vois pas, moi...

      > - La Xlib est obsolète et trop difficile à utiliser, les programmeurs
      > s'orientent donc vers un autre toolkit. Quel intérêt d'avoir une Xlib si
      > personne l'utilise ?
      Ben en gros, tous ceux qui utilisent d'autres toolkits utilisent Xlib. Bon, je suppose que tu veux dire "à quoi sert d'avoir unz API à ce niveau si elle n'est pas utilisée"?
      Noter que si la prochaine version de X.org, cet été, ne changera pas de ce point de vue, il est possible que la suivant soit prête pour XCB/XCL.

      > - X11 n'a pas de toolkit en standard, pas moyen de construire une
      > application graphique, il manque trop de composants.

      Moi j'aime bien, comme ça on peut choisir son toolkit :)
      C'est bien le genre "unix n'a pas de shell standard",

      > - X11 arrive en fin de vie.
      Ah bon?

      > Les maintes modifications et extensions
      > faites en dix ans font de X11 un désordre incohérent. Certaines
      > nouvelles extensions interférent avec d'autres plus anciennes.
      Nettoyage en cours dans X11, non?

      Pour le reste, c'est technique, jesépa.
      • [^] # Re: X11 doit-il mourir ?

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

        > X11est trop lent.Ca rame et ça saute aux yeux.
        >> Je ne vois pas, moi...
        C'est que tu manques de points de références ou que tu t'es habitué aux temps de latence de X11, qui bien sûr ne rendent pas X11 inutilisable. Attention ces temps de latence ne sont pas évalués en secondes bien entendu. Mais ils empêchent l'utilisateur d'avoir la sensation d'un bureau fluide et propre.

        > Noter que si la prochaine version de X.org, cet été, ne changera pas de ce point de vue, il est possible que la suivant soit prête pour XCB/XCL.
        Merci pour l'info ! Très bonne nouvelle :-)
        La page suivante énumère d'ailleurs les limitations de la Xlib :
        http://www.freedesktop.org/Software/xcb(...)

        > - X11 n'a pas de toolkit en standard, pas moyen de construire une
        > application graphique, il manque trop de composants.
        Moi j'aime bien, comme ça on peut choisir son toolkit :)

        C'est bien et c'est pas bien. Le revert de la médaille :
        - implémenation de couches supplémentaires
        - une plus grande consommation de mémoire
        - un manque d'harmonisation des applications
        - une fragmentation du bureau Linux
        Les deux dernières points peuvent rebutter un développeur qui désire écrire une application graphique Linux. Que vais-je utiliser ? KDE, Lesstif, GNUStep, Gnome, GTK, Qt, WxWidget ?

        > X11 arrive en fin de vie.
        >> Ah bon ?

        C'est les propos de Marks Thomas du projet Y Windows. Et pour moi c'est plus une question q'une affirmation, j'attends de voir les prochaines versions de X.org.

        Nettoyage en cours dans X11, non?
        Oui à mon humble avis X11 a besoin d'un bon nettoyage, d'un bon dégraissage et de nombreuses optimisations, s'il ne veut pas se faire bouffer par des projet comme DirectFB.
    • [^] # Re: X11 doit-il mourir ?

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

      Corba est un middleware !!
      Pas un protocole !!!!

      Faut finir les docs, pas juste commencer à les lire !
  • # Et Debian ?

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

    Debian (unstable) utilise encore XFree86, non ?
    Une recherche de xorg dans les paquets de unstable donne :
    http://packages.debian.org/cgi-bin/search_packages.pl?keywords=xorg(...)
    rien du tout !

    Une recherche de xfree86 donne :
    http://packages.debian.org/cgi-bin/search_packages.pl?keywords=xfre(...)
    "Package xserver-xfree86"

    Bon c'est la version 4.3.0 ok, mais c'est xfree.
    Ont ils prévu de passer sous X.org dans le futur ?
    • [^] # Re: Et Debian ?

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

      Le but de Debian a toujours ete de proposer le maximum de choix aux utilisateurs . Sauf qu'il me semble qu'xorg ne sera pas integre dans la Sarge d'ou sont non packageage pour le moment. Mais il y a de forte chance qu'il apparaitra rapidement apres la sortie de cette release. Bien sur, comme a son habitude, Debian laissera le choix aux utilisateurs, et XFree 4.3.0 restera disponible. Et je ne doute pas qu'il y aura de forte chance de trouver des packages 4.4.0 dans un coin ;).

Suivre le flux des commentaires

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