Les nouveautés du prochain X11R6.8

Posté par . Modéré par rootix.
Tags :
0
27
août
2004
Serveurs d'affichage
Le groupe freedesktop.org est sur le point de sortir une nouvelle version de X11, qui s'appellera X11R6.8.
C'est la 1ère version majeure depuis la séparation avec XFree86, dont le but est clairement de remplacer XFree86. Les pilotes binaires ATI et nvidia sont supportés. On peut surtout noter le nombre impressionnant de nouveautés, dont :
  • XDamage extension: permet aux applications de détecter les zones de fenêtre modifiées (considéré comme prêt)
  • XComposite extension: permet d'avoir de la "vraie" transparence et non plus de la pseudo transparence (comme c'est le cas pour les émulateurs de terminaux aterm, gmt, konsole, ...) (voir les captures d'écran) (pas tout à fait considéré comme prêt)
  • XEvIE (X Event Interception Extension) : permet à l'utilisateur de détecter plus facilement les évènements en provenance du clavier ou de la souris (expérimental, désactivé par défaut)
  • XFixes extention : extension "fourre-tout" (considéré comme prêt)
  • DMX (Distributed Multihead X) : permet de combiner les affichages de plusieurs machines (contrairement à Xinerama, qui utilise les affichages d'une seule machine)
  • les incontournables corrections de bogues
  • les incontournables mises à jour de pilotes

La liste est vraiment impressionnante et je vous suggère de jeter un oeil à la liste des changements (« changelog »).
Le plan de travail (« release plan ») donne un bon aperçu des nouveautés et est plus court et synthétique que le changelog.

Ars Technica propose une interview de Daniel Stone : elle permet à Daniel de se présenter. On y parle d'organisation, des projets, des X.org 6.7 et 6.8, de NVidia et d'ATI, de freedesktop.org, des distributions, de GNOME et KDE, des noyaux Linux et BSD, et de contributions au projet.

Aller plus loin

  • # X.org avance à grand pas !

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

    Et oui X.org avance à grand pas et une nouvelle version devrait sortir aujourd'hui même :-)

    A noter l'entrevue avec Ars Technica et de Daniel Stone
    http://arstechnica.com/etc/linux/index.html(...)

    Un article de Linux Gamer sur le futur X11R6.8 :
    http://www.linux-gamers.net/modules/soapbox/article.php?articleID=5(...)

    Sinon à lire les papiers et conférences de Keith Packard, qui prouve que X.org prends la bonne direction :
    http://keithp.com/~keithp/talks/(...)

    J'ai bien aimé le document "The (Re)Architecture of the X Window System" de James Gettys et Keith Packard qui montre bien que les développeurs X.org sont conscients des lacunes de X11 et des des solutions à apporter :
    http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/(...)
    • [^] # Re: X.org avance à grand pas !

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

      Après avoir été très décevante, l'attitude de l'équipe de XFree86 aura finalement été bénéfique: ça donne un nouveau souffle au projet :-)
      • [^] # Re: X.org avance à grand pas !

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

        Les idées d'une personne sont bien moins bonnes que celles de cent personnes. On peut le voir dans toutes les dictatures ou entreprises où le culte de la personne devient la règle et se traduit par une régression.
        Ce qui se passe maintenant, c'est la libération des énergies qui étaient bloquées par le chef. Avec le logiciel libre, on fait un fork, dans la vie politique, une révolution et dans l'entreprise, on attend qu'elle ferme...
        • [^] # Re: X.org avance à grand pas !

          Posté par . Évalué à 0.

          Petit bémol: un chameau est un cheval défini par un comité ;-)

          Le projet qui dépend in fine d'une seule personne n'est pas nécessairement moins bon que celui qui dépend d'un grand nombre de personnes, le problème fondamental est de savoir comment cette personne gère le projet. Ex: linux, perl, ...
    • [^] # Re: X.org avance à grand pas !

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

      C'est impressionnant les progrès qui arrivent aussi vite. Du coup, on se rend compte combien la structure conversatrice de XFree(86) et combien le bloat-code pouvaient brider les développeurs.

      Et le fait que KP aie non seulement un fork déjà viable mais adossé au X consortium est littéralement extraordinaire..

      Il était temps : la transparence existe nativement en Mac Classic depuis Mac OS 8.6, sous Windows depuis Windows 2000, et impossible de créer de bonnes applis critiques audiovisuelles sous XFree(86) du fait du nombre incroyable de lenteurs et de lourdeurs.

      De nombreuses distribs séparaient déjà les serveurs, clients et accessoires, mais il était nécessaire de remettre bien des choses à plat. C'est une très bonne direction que prend X.Org, surtout que de nombreuses extensions viennent de desirata exprimés depuis longtemps par les codeurs : XEvIE pour le Gbnome Accessibility, XCB/XCL pour Enlightenment, ...

      En un mot : OUF !
    • [^] # Re: X.org avance à grand pas !

      Posté par . Évalué à 10.

      Keith Packard a l'air de savoir où il va, sauf sur le point Compression and Image Transport. Pourtant ce qu'il décrit m'a tout l'air de correspondre à ce qu'a accompli NoMachine avec sa technologie NX sur laquelle KDE mise beaucoup en ce moment. Je me trompe ?

      (PS: le protocole est documentée et l'implémentation des bibliothèques est libre)
      http://www.nomachine.com/documentation/NX-XProtocolCompression.php(...)
      http://www.nomachine.com/documentation.php(...)
      • [^] # Re: X.org avance à grand pas !

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

        J'ai testé NX ily a quelques jours, et ça m'a plutot bluffé(tes sur leur serveur fait pour ça sur internet), par rapport à un vnc il n'y a pas photo! Par contre je ne sais pas ce que ça donne en plus bas débit que l'adsl (et plus grande latence)par rapport à un citrix ou un TSE, même si NX dit que c'est prévue pour...

        Mais bon j'ai l'impresionque NX est une concaténation de projets libre (DXPC,openssh/openssl, etc.), ce qui explique le faible prix pour une entreprise(si ça marchait aussi pour les serveurs windows, en mettant un serveur NX dessus, j'en connais qui serais intéressé par rapport à Citrix!) mais par contre je ne crois pas que ce soit libre (sinon ils auraient du mal à le vendre!). Je ne sais pas si il viole la GPL à leur profit ou pas en bref.
        • [^] # Re: X.org avance à grand pas !

          Posté par . Évalué à 7.

          par contre je ne crois pas que ce soit libre (sinon ils auraient du mal à le vendre!).
          =========
          Et pourtant si, c'est écrit en gros sur la page d'accueil :
          Join us . NX Core is Open Source qui te mène ici :
          http://www.nomachine.com/developers.php(...)

          Seuls les outils d'administration et autres qui rendent ça plus user-friendly ne sont pas sous GPL, mais même là, KDE intègre sa propre solution depuis le LinuxTag et akademy (j'ai la flemme de trouver un lien).
        • [^] # Re: X.org avance à grand pas !

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

          J'ai testé NX ily a quelques jours, et ça m'a plutot bluffé(tes sur leur serveur fait pour ça sur internet)
          Moi aussi j'ai essayé. Seulement je n'ai pas pu me faire une vraie idée la-dessus: la bande passante vers leur serveur doit être ma bande passante de download (64ko/s à l'époque). Ce qui m'intéresse c'est de me connecter chez moi avec la bande passante ADSL limitée en upload. À l'époque je ne savais pas que je pouvais essayer en mettant de la QoS coté client.
          • [^] # Re: X.org avance à grand pas !

            Posté par . Évalué à 4.

            [NX] Ce qui m'intéresse c'est de me connecter chez moi avec la bande passante ADSL limitée en upload.

            Je l'ai essayé plus d'une fois depuis le boulot, ça marche vraiment bien, ils ont fait du beau boulot les développeurs de NoMachine. Au lieu qu'un menu mette quelques secondes à s'ouvrir, c'est presque instantané; une application qui était inexploitable à distance (je n'arrivais pas à ouvrir un menu contextuel et ensuite à me ballader dedans) l'est redevenue. Ca sera bien quand ce sera intégré à KDE.
            • [^] # Re: X.org avance à grand pas !

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

              Je viens de réessayer de chez moi et ça marche du tonnerre . Même avec une bande passante encore plus limitée que 16ko/s, c'est utilisable (tant qu'on ne regarde pas une page web pleine de grosses images), ce qui n'était pas du tout le cas avec TightVNC.

              Pour limiter la bande passante en download:

              tc qdisc del dev eth1 ingress
              tc qdisc add dev eth1 handle ffff: ingress
              tc filter replace dev eth1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 16kbps burst 18k drop flowid :1
  • # Bonne news

    Posté par . Évalué à 9.

    En voilà une bonne news !
    Claire, étoffée, précise, et fournie en liens.

    Merci.

    Pour ceux qui se demandent si ça marche vraiment X.org, je peux répondre que oui : ça fait un moment que j'utilise le CVS en le mettant à jour régulièrement. Ça marche farpaitement, accelération nickel avec une radeon M9, le tout en GPL. Que demande le peuple (à part une modularisation - prévue - de tout ce bordel) ?
    • [^] # Re: Bonne news

      Posté par . Évalué à -10.

      'En voilà une bonne news !"

      T'es vraiment sur de toi ?

      "Les pilotes binaires ATI et nvidia sont supportés".

      Perso, je trouve pas ça une "bonne" news.
      • [^] # Re: Bonne news

        Posté par . Évalué à 5.

        faut pas confondre le fond et la forme ...
        • [^] # Re: Bonne news

          Posté par . Évalué à -1.

          tu peux developper, ou tu dis ca juste pour la forme ?
      • [^] # Re: Bonne news

        Posté par . Évalué à -5.

        Tu voudrais des pilotes vidéo en GPL ?

        On ne peut pas donner au concurrent les spécification de sa bête

        Ils seront toujours des binaires proprios
        • [^] # Re: Bonne news

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

          "On ne peut pas donner au concurrent les spécification de sa bête"

          Le probleme n'est pas vraiment la, le probleme, c'est de ne surtout pas donner le code de son driver. Et quand on code soit meme son driver, y'a plus d'interet à donner les specs aux devels libres(surtout que ils ne peuvent pas tout donner), c'est une logique d'entreprise.... :(

          Vous trouverez aussi plus d'info sur le forum de nvidia, les devels ont deja expliqué le pourquoi du comment, a de nombreuses reprises vu que la question des "GPL drivers" revient en permanence sur ce forum.

          J'en ai deja parlé hier.
          http://linuxfr.org/comments/465168,1.html(...)


          Et ATI est entré dans la danse de Nvidia. En meme temps, avant la radeon 8500, les drivers ATI etait merdique sous Windows et on comprend que ati n'avait pas le temps de bosser sur ses propres drivers pour Linux, c'etait tellement plus simple de laisser bosser les gens du libres...

          M'enfin il ne faut pas oublier que tout ce que Nvidia développe à coté de son driver est GPL : installeur et nvidia-setting. De plus, j'ai deja vu des patchs from @nvidia.com dans Mesa. Certe, un devel de chez nvidia peut le faire sur son temps libre mais c'est deja pas mal que le boite le laisse faire :)
      • [^] # Re: Bonne news

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

        Je vois pas le pb. On n'a pas dit qu'il ne fallait pas de driver opensource ni que ces derniers seront jetés. Il s'agit juste de vérifier que des binaires très utilisés marchent encore.

        Dans ce cas le contraire de "Les pilotes binaires ATI et nvidia sont supportés" c'est "Les pilotes binaires ATI et ne nvidia sont pas supportés". Ca ne veut certainement pas dire "Les pilotes ATI et nvidia seront des binaires".
      • [^] # Re: Bonne news

        Posté par . Évalué à -5.

        vu le score, je pensais pas qu'il y avait autant de proprietaire de nvidia et ati... héhé.

        D'aileurs si on pouvait m'éclairer sur le fait que mes posts sont immediatement -1 ou -2 à peine postés... (je pense pas que qq1 guette 24/7 le moment précis ou je vais poster...)
        • [^] # Re: Bonne news

          Posté par . Évalué à 1.

          Tu n'as pas été assez attentif ces derniers temps...il y a en effet eu une évolution du mode de notation. Maintenant ton post a un score par défault basé sur les scores de tes derniers messages.
          A mon humble avis c'est une très mauvaise idée, c'est un "préjugé", donc quelque chose de fondamentalement mauvais selon mon éthique.
          • [^] # Re: Bonne news

            Posté par . Évalué à -2.

            "basé sur les scores de tes derniers messages"

            Je comprends mieux pourquoi certaines personnes s'acharnent.

            "c'est une très mauvaise idée, c'est un "préjugé" [...]"

            Ca forme aussi un club encore plus fermé de potes qui pensent la même chose ou qui sont tolérés. C'est une jolie ironie pour un site ou les mots liberté et ouverture sont clamés à tous les vents.

            Enfin bon, c'est probablement mon dernier post, puisqu'à priori je ne peux pas poster sur le forum, ni faire un journal.

            Je ne fais pas parti du club, et j'en fais pas une maladie.

            Bye bye linuxfr, et peut être à bientôt, lorsque le système de notation, et donc la politique du site aura changé.
    • [^] # Re: Bonne news

      Posté par . Évalué à 0.

      modularisation prévue de tout ce bordel

      C'est comme le projet E17 qui est lui aussi grandement modulaire. Vu la complexité de l'implémentation, il est tout à fait logique de séparer les composantes. Puisque E17 comprend du nouveau code, on peut espérer qu'il aura une excellente gestion des fenêtres. Notons qu'avec E16 j'ai toujours le bug des miniatures qui disparaissent de l'écran quand je redémarre E, problème qui se pose également avec FVWM
  • # Des shoots qui tuent

    Posté par . Évalué à 1.

    Heu ... question, comme ça, en passant ; tous ces thèmes présentés en exemple (comme celui-là http://ruinaudio.com/Xorg-xcompmgr.png(...) ), ils sont dispos quelque part ?
    Non parce que je le trouve carrément excellent
    • [^] # Re: Des shoots qui tuent

      Posté par . Évalué à 2.

      oui oui ca se trouve.
      Sur art.gnome.org notamment (puisque q'apparemment c'est un gnome qui tourne) sinon si t'utilises gentoo dois y avoir un ebuild avec ces icônes là (genre gnomes-themes-extras), le reste je sais pas ca me dit rien.
    • [^] # NUVOLA :)

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

      http://kdelook.org/content/show.php?content=5358(...)

      N'ai pas peur de cliquer, y'a aussi la version gnome ;) Bon, apres, c'est clairement pas un theme gnome donc mal adapté à gnome (ie incomplet) alors que sous Kde il rosk et j'espere bien qu'il remplacera crystal dans kde 4.0 (vu que c'est le numero 1 sur kdelook, ca serait logique).

      Pour le theme gtk, y'a une adaptation de Lush pour Nuvola mais je sais pas ou :) Cherche :)
      • [^] # Re: NUVOLA :)

        Posté par . Évalué à 3.

        Il ressemble beaucoup à Plastik ce thème ... (d'ailleurs, Plastik n'était-il pas déjà le thème par défaut de KDE 3.2 ... ou prévu pour le 4 ? Ou je raconte n'importe quoi ?)
        • [^] # Re: NUVOLA :)

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

          Il me semble que c'est Keramik le thème par défaut. Plastik ne semble être là qu'en guise de clone de Win XP (ce serait pour le moins troublant qu'il soit donné par défaut, bien qu'il soit assez réussi).
          • [^] # Re: NUVOLA :)

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

            Plastik sera le theme par defaut de kde 4.0.

            Apres, le theme Qt n'a rien avoir avec windows, par contre, il est vrai que le theme kwin a un arriere gout de longhorn build jesaispluscombien.
            • [^] # Re: NUVOLA :)

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

              Hum, le theme Plastik est un authentique clone du theme par défaut de Win XP, je vois mal comment on peut contester cela.
              • [^] # Re: NUVOLA :)

                Posté par . Évalué à 4.

                je vois mal comment on peut contester cela.

                En utilisant ses yeux pardi , je vois vraiment pas en quoi plastik , hormis le theme kwin ressemble au theme playskool de winxp , ou alors tu confonds avec keramik , qui lui , est clairement playskool .
              • [^] # Re: NUVOLA :)

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

                Inspiré, oui, mais lui au moins il est réussi.
        • [^] # Re: NUVOLA :)

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

          Nuvola, ce sont les icones ;) Oui, le theme kde que tu vois c'est plastik ;)

          Sur le screenshot gnome du monsieur, y'a nuvola pour les icones et un version nuvola(les icones gtk) du theme Lush(il me semble).
      • [^] # Re: NUVOLA :)

        Posté par . Évalué à -3.

        hum... ça ressemble beaucoup à MS Windows ce truc.
    • [^] # Re: Des shoots qui tuent

      Posté par . Évalué à 1.

      Pour les fenêtres, tu trouveras ton bonheur ici : http://gooeylinux.org/forums/index.php?showtopic=772(...)

      a+
  • # j'ai testé

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

    j'ai installé X11R6.7.99.902 aujourd'hui (une des dernieres versions avant la release 6.8) et j'ai pu testé ce que pouvait valoir cette intrigante extension XComposite. En effet, il s'agit bien d'une réelle transparence, toute la fenetre est transparente en fait, et par exemple si je fait tourner un mplayer (transparent ou non) sous un xterm transparent on voit que ça continu a s'animer en dessous :) (ceci dit le mplayer transparent ça vaut le detour !). Non seulement il s'agit bien là de vraie transparence mais en plus ça bouffe pas plus de ressource ! (j'ai regarder la charge de cpu, quand je deplace une fenetre transparente, on voit le decors qui defile par dessous de façon instantané et ça n'excède pas les 5%), donc a mon avis ça doit prendre en compte les extensions 2D de la carte graphique.

    Par contre XComposite a l'heure actuel ne semble pas supporter la transparence sur Xv et l'OpenGL.

    ah oui au fait, je me suis aidé de de lien pour tester la transparence : http://www.neowin.net/forum/index.php?showtopic=204593(...)
    • [^] # Re: j'ai testé

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

      J'ai aussi testé, mais j'ai du bien et du mauvais :

      Le bien :
      - C'est très beau, vraie transparences, les ombres sont jolies

      Les moins :
      - C'est TRES lent chez moi : c'est que je lance xcompmgr (le manager composite pour activer tout ça), ça se mets a ramer et j'ai des latences de X phénoménales. Il s'agit peut-etre d'un probleme de conf, mais j'ai suivit les infos que j'ai trouvé (dont le lien donné ci dessus)
      - Ca a fait planter X avec les drivers nvidia, mais ça marche avec nv (toujours aussi lent)
      - Dès que xcompmrg est lancé, les barres de titre sont déformée (jai constaté que je ne suis pas le seul a avoir ce probleme apparement, j'ai trouvé des screenshots montrant le meme probleme), ça ressemble à ça, et ça semble indépendant du WM utilisé :
      http://xwing.info/screen.png(...)
      http://freedesktop.org/bugzilla/attachment.cgi?id=707&action=vi(...)


      Sinon, si on ne lance pas xcompmgr, il marche très bien (pas vu de différence avec 6.7.0)
      • [^] # Re: j'ai testé

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

        J'ai fait le test avec les drivers proprio de nvidia (la derniere release 6111), je n'ai pas remarqué quelconque problème de stabilité.
        Aujourd'hui je viens de faire le test avec les drivers libre (nv), et c'est vrai que du coup ça s'est avéré très très lent :/.
        Est-ce que cela vient du fait que le driver libre de nvidia ne supporte pas entièrement les fonctions accélératrices 2d des cartes ou bien c'est le fait que XComposite utilise l'OpenGL pour gérer la transparence ?

        Ensuite j'ai fait des tests sur quelques windowmanager, avec openbox ya comme des gros bugs d'affichage au niveau du menu et de la barre de titre, de meme que enlightenment, fluxbox, xfwm. fvwm2, c'est presque ça...
        Par contre ça se passe plutot pas mal avec gnome/metacity, windowmaker, ion (la transparence sous ion, ben ouais pourquoi pas ;) ) et wmi.
        Autrement j'ai remarqué que firefox n'aimait pas trop se faire chatouiller par XComposite : quand on fait un defilement d'une page de dlfp.org vers le bas, ben ya la toolbar qui "flood" sur toute la page..

        Bon ya pas trop à s'alarmer de toute façon, c'est une technologie qui vient d'être introduite et qui demande à être beta-testée puisque comme dit la news c'est pas encore tout à fait pret :). De toute façon, la balle est maintenant dans le camp windowmanager pour la prise en compte de cette extension afin qu'ils puissent nous proposer des fonctionnalités alléchantes.

        Bref, à vos compilos !

        PS : pour XDamage, c'est au windowmanager de prendre en compte cette extension pour quelle soit utilisée ?
      • [^] # Re: j'ai testé

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

        Pour les drivers nvidia, il faut activer renderaccel pour que ca soit correct niveau performances.

        Sinon, pour ton bug, il a l'air corrigé dans le dernier snapshot.
        • [^] # Re: j'ai testé

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

          Oui, avec la rc3, (6.7.99.903) cela marche mieux.
          Cependant, avec une carte non accélérée (exemple, mon portables avec une i810), c'est peine perdue, c'est lent et inexploitable
  • # Debian ?

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

    Question : quelqu'un sait où ça en est la mise en paquet Debian de X.org ?

    Quand la Sid ava t'elle utiliser par défaut X.org au lieu de Xfree ?

    Toutes les infos ou liens vers les messages de mailing list concernés sont les bienvenus, j'ai l'impression que c'est un sujet tabou chez Debian, personne n'en parle.
    • [^] # Re: Debian ?

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

      Une partie de réponse à moi-même dans l'interview de Daniel Stone :

      You're also a member of Debian's X Strike Force. Once Sarge is released, what's the plan for Debian?

      Once Sarge is out the door, we have a reasonable amount of time before we have to freeze X again (it's already frozen for Sarge), so we have a pretty fair amount of time to think about the future. We're one of the few distributions still back on XFree86, so we're not tied to modular or monolithic, which means we have the luxury of sitting back and evaluating each on their merits.

      In the coming weeks, we'll certainly be looking closely at all our options, and deciding where to go from there.
    • [^] # Re: Debian ?

      Posté par . Évalué à -10.

      je ne veux pas troller, franchement...
      mais quel est l'intérêt d'une Debian?
      être à la bourre pour je ne sais quel raison (rajoutent-ils vraiment qqchose au programme? si ce n'est leur divine approbation?)
      oui on peut passer en "instable" (terme douteux) , je sais...

      Si vous voulez être super à jour, oublié Debian sinon, posez ce genre de question directement dans le forum adéquat. ce n'est pas de l'exclusion abusive, mais bon vous vous engagez à utiliser Debian dés lors vous vous engagez pour les incovénients* également.

      La Slackware qui est maintenue par un gars (principalement) est de loin supérieure à cette `certifié conforme par le haut saint` Debian.
      Je l'ai utilisé, je parle donc en connaissance de cause.


      Je ne cherche pas à vous convaincre/imposer quoique ce soit, je veux juste comprendre pourquoi vous vous compliquez la vie?
      • [^] # Re: Debian ?

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

        Si la debian est a la bourre c'est parce que le support inter-architecture est complet, cad qu'ils ne font pas de cadeaux aux possesseurs de x86 avant les autres, quand un package sort, c'est pour toutes les archis, donc ca prend du temps. Mais y'a surement des packages non officiels pour la debian.
        • [^] # Re: Debian ?

          Posté par . Évalué à 6.

          ils ne font pas de cadeaux aux possesseurs de x86 avant les autres, quand un package sort

          C'est un truc que je n'ai compris chez Debian. J'apprécie beaucoup cette distribution (je l'utilise partout - unstable sur le bureau, stable pour un petit serveur) mais cette politique ne me parait pas logique. Si un logiciel n'est pas prévu pour tourner sur l'architecture ZZZ supportée par Debian les packageurs se font chier à faire un portage et les paquets correspondants. Pour moi ce n'est pas leur rôle. Si SuperSoft 1.0 ne tourne pas sur Vax, c'est à l'équipe de SuperSoft qu'il faut s'adresser. Ce n'est pas au packageur de réécrire le code. On se retrouve à attendre des packages X pendant des lustres pour faire plaisir aux 2 utilisateurs de Vax.

          J'irais un peu plus loin : Porter tous les logiciels sur toutes les architectures n'a pas de sens. Un logiciel pour PDA ne tourne pas sur mainframe ? Et alors ? Idem dans l'autre sens. Si un SGDB ne tourne pas sur PocketPC on s'en contrefout. Personne n'aurait l'idée de l'installer là dessus. Je pense que le pool de logiciel devrait être divisé en catégories : base, bureau/station de travail, serveur, mobile. Et on ne devrait pas s'occuper de porter des logiciels serveurs sur téléphone portable. Si ça tourne tant mieux, dans le cas contraire tant pis.
          • [^] # Re: Debian ?

            Posté par . Évalué à 9.

            «cette politique ne me parait pas logique.»

            Le but c'est de proposer un système d'exploitation, Debian. Quand on arrive sur une machine sur laquelle il y a "Debian", alors on a la garantie que les logiciels contenus dans Debian tournent sur cette machine, quelle que soit son architecture. Sinon, à quoi sert d'avoir le même nom pour des distributions qui seraient différentes ? Il ne s'agirait plus de Debian, mais de LinuxPourPPC, LinuxPourX86, etc. qui seraient des distributions différentes, car ne contenant pas les mêmes logiciels.

            «Porter tous les logiciels sur toutes les architectures n'a pas de sens. Un logiciel pour PDA ne tourne pas sur mainframe ? Et alors ?»

            Debian ne supporte pas toutes les architectures, elle en supporte un certain nombre.
      • [^] # Re: Debian ?

        Posté par . Évalué à 8.

        je veux juste comprendre pourquoi vous vous compliquez la vie?

        Très simple: ça marche. En une demi-heure chrono (dernière install, lorsque j'ai viré FC2)
        J'ai testé pas mal de distros sur du long terme, genre fedora ou gentoo, j'ai jamais réussi à dépasser les 6 mois.
        Je veux dire, une fois en FC2, bah c'est figé, tu es en FC2. Pareil en Mandrake 10, etc.
        Gentoo, bon, j'aime pas essuyer les plâtres, et je peux te dire qu'en 9 mois de gentoo j'en ai essuyé.

        Debian évolue chaque jour. Peut-être avec retard à ton gout, mais perso je n'ai pas besoin du bleeding edge. J'ai besoin d'un quelquechose de récent, stable, fonctionnel, efficace, et surtout, valable sur le long/très long terme.
        Debian/unstable remplit à mon goût parfaitement ces critères.
        • [^] # Re: Debian ?

          Posté par . Évalué à 4.

          C'est tout ce que je demandais Jean-Baptiste, merci d'avoir répondu à la question par ton point de vue plutot que le "moinssage" barbare même si t'y a pris part :).
          Toutefois la réponse n'est pas complète, est-ce que la team Debian rajoute qqchose au dit paquet? <-- surtout ça que je veux savoir.

          Ce n'est pas le sujet d'un enième combat puèrile de distro, mais en temps qu'utilisateur de Gentoo depuis sa version 1.2 je peux affirmer que je n'ai jamais été laisé et combien même un paquet m'aurait fait défaut une simple correction (désinstallation/rapport de bug du paquet sensible) arrange le coup. Ah également, je n'ai surtout pas - sur un forum généraliste - demandé quoique ce soit à propos de la distro que j'utilisais - non pas que ça soit interdit- mais pour la simple et bonne raison qu'il y avait des endroits plus pertinent.

          Je comprend - à 50% - bien que ce genre de sujet soit sensible, désolé donc de cette digression mais le fait est que c'est tjrs la même rengaine avec les Debianistes - par qui je vais pas tarder à me faire "RE-moinser"- à savoir :"Quand c'est qu'ils préparent un paquet Debian pour sid-sarge-woody-etconsort?"
          ça à l'air de rien, mais ça m'a un peu effrité qu'on pose cette question et encore, avant même la date de sortie officielles.


          bye
          • [^] # Re: Debian ?

            Posté par . Évalué à 3.

            « est-ce que la team Debian rajoute qqchose au dit paquet? »

            Des potions magiques, des sorts, etc ...
            Attention a ce que tu dit, il pourrait t'arriver des ennuies, St Ian Murdock veille ...

            Non sérieux, tu devrai jeter un coup d'oeil par là : http://www.debian.org/(...)
            ça repondra à beaucoups de tes questions.
            Désolé, le troll ne prend pas :)
          • [^] # Re: Debian ?

            Posté par . Évalué à 3.

            «Quand c'est qu'ils préparent un paquet Debian [...] ça m'a un peu effrité qu'on pose cette question et encore, avant même la date de sortie officielles.»

            Ce n'était pas une question concernant cette version là en particulier, c'était une question sur la disponibilité de X.org en général, et sur le remplacement de XFree86. C'est donc un peu plus que "quand est-ce que ça sera dispo dans ma distrib à moi ?".
        • [^] # Re: Debian ?

          Posté par . Évalué à 3.

          > Je veux dire, une fois en FC2, bah c'est figé

          Bof...
          J'étais en RH9 puis FC1 et maintenant FC2. Ça bouge. Pas en continu, certe.
          De plus, comme il y a peu de problème avec FC3T1 + rawhide, j'attend FC3T2 pour y basculer de façon permanente et être synchro avec rawhide (en phase de stabilisation pour la sortie de FC3) et "profiter" (Xorg 6.8.0, Gnome 2.8, udev/hal, etc).

          Donc ce n'est pas si figé que ça.

          Par contre, tu peux me dire que les mises à jours d'OS tous les 6 mois sont chiantes.
          Je suis d'accord.
        • [^] # Re: Debian ?

          Posté par . Évalué à 2.

          Oui mais Debian sur AMD64 j'ai testé et ça marche pas du tout vu que toutes les dépendances sont toutes cassées dans tous les sens.

          Il y a des cas où on n'a pas le choix :(

          Donc pour moi c'est Gentoo (ça m'apprendra à acheter des machines bizarres).
          • [^] # Re: Debian ?

            Posté par . Évalué à 1.

            > Il y a des cas où on n'a pas le choix :(

            Fedora existe pour AMD64. Si on ajoute Gentoo et Debian, ya le choix.
      • [^] # Re: Debian ?

        Posté par . Évalué à 2.

        «mais quel est l'intérêt d'une Debian?»

        Depuis que j'utilise des ordinateurs (PC), c'est avec Debian que je suis arrivé à ce que je voulais: ne (presque) jamais rien avoir à faire au niveau administration, une fois que c'est installé. Je me contente de la mettre à jour régulièrement, et tout se passe parfaitement bien. L'installation et le retrait de paquets est parfaite, dans le sens où je n'ai pas à m'en occuper, juste à lui dire quel paquet je veux.

        Note que je ne dis pas que seule Debian permet cela, simplement j'ai utilisé pas mal d'OS (et de distributions dans le cas de GNU/Linux), et c'est pour l'instant la seule qui m'ait semblé aussi bien foutue. Pour moi, ne pas perdre 30 minutes de temps en temps à régler des problèmes, ça vaut largement l'attente des paquets, qui est souvent assez courte.
        • [^] # Re: Debian ?

          Posté par . Évalué à 3.

          > ça vaut largement l'attente des paquets, qui est souvent assez courte.

          *kof* *kof* *kof* ... Non rien :)

          Il faut arrêter de faire croire que les nouveaux paquetages de Debian arrivent rapidement dans Debian, c'est mentir par omission et ça ne sert pas la cause de Debian : Tu ne parles de Debian stable mais de la version de développement de Debian. À cause de cela, combien de nouveaux venus sont supris de voir que leur Debian est à la traîne et qu'ils doivents passer à la version de développement de Debian pour en bénéficier !

          D'autre part, tu dis que les nouveaux paquetages arrivent assez rapidement dans Debian : comment peut-on donc expliquer les multiples trolls, demandes, requêtes, plaintes à propos de l'intégration prochaine de tel ou tel paquetage dans Debian ici et là.

          Enfin, Debian est la seule distribution populaire à encore utiliser XFree86 controversé pour son changement de licence, bel exemple de réactivité quand on voit les trolls historiques sur les listes de diffusion Debian face à telle ou telle licence ! Sûrement que les responsables des paquetages doivent encore troller sur les listes de diffusion sur la nécessité du passage à X.Org, bien qu'ils y pensent fortement aux dernières nouvelles ...

          « 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: Debian ?

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

            Combien de distribution supporte un serveur X sur 11 architectures différentes en simultanée? A ma connaissance; seule Debian, et de loin.

            Pour la version 4.3 d'Xfree, les mainteneurs Debian ont patché pour plus de 110000 lignes de code afin que les architectures non-x86 puissent également profiter d'une version récente du serveur X. Et ca, ca prend du temps.

            On est loin des autres distrib qui se contente d'avoir une compatibilité x86 et puis basta. Parfois ils vont jusqu'à sortir une version PPC, et encore, rarement en même temps que la version x86.

            Alors ne compare pas une RH, Mdk ou Suse avec Debian question disponibilité de paquets récents. Qui a les paquets les plus récents à la fois pour SPARC, HPPA, PPC, s390, Alpha, 68k, ARM, MIPS, MIPSEL, ia64 et x86 ? Si tu tournerais sur autre chose que du x86, tu serais très content du boulot fourni par les developpeurs Debian.
            • [^] # Re: Debian ?

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

              En même temps avoir la distrib sur 11 architectures je suis sûr que ça sert à des gens mais qui ici utilise Debian sur plus d'une ou deux archi ?

              Ben oui, pour la plupart des gens (même en entreprise) il y a besoin que les paquets soient prêts sur une ou deux architectures seulement : celles qu'on utilie. Et finalement quand les paquets sont retardés pour le support des 9 qu'on utilise pas, c'est toujours un retard inutile (du point de vue utilisateur).
              Supporter tout ça c'est bien, très bien (ça doit être très chiant d'être sous autre chose que x86 et voir la plupart des possibilité s'envoler par manque de support des distrib). Mais est-ce que forcément tout e monde doit attendre le portage de tout ?
              • [^] # Re: Debian ?

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

                mais qui ici utilise Debian sur plus d'une ou deux archi ?

                Moi. J'utilise actuellement sur x86, x86-64, PPC, Sparc32 et Sparc64.

                Et je suis bien content de retrouver *tous* mes petits quand je
                passe d'une architecture à l'autre.


                --
                Ma pharmacienne est moins contente, certes, car je ne lui achète
                quasiment plus d'aspirine :o)
                • [^] # Re: Debian ?

                  Posté par . Évalué à 0.

                  Pareil pour moi:
                  x86, IA-64, HPPA et meme un peu de Sparc32
                  Parfois je suis oblige de regarder dans le /proc/cpuinfo pour me rappeler ce que c'est comme bestiole.
            • [^] # Re: Debian ?

              Posté par . Évalué à 5.

              J'ai un doute sur le fait que tu utilises vraiment Debian sur d'autres archis que du X86....parce que moi oui, et bien je peux te dire que ça casse pas des briques du tout.
              Il suffit pas de dire ma distrib sort un version HPPA et une autre MIPS donc ça justifie tout le reste car ce n'est qu'un cache-sexe, non seulement ces versions ne sont que très peu utilisées, mais en plus elles fonctionnent très mal !!! Moi qui les ai testées je peux en témoigner, et retarder des millions de gens en X86 pour ça ça vaut vraiment pas le coup...mais en fait ce n'est qu'une fausse excuse pour expliquer le manque de réactivité du model de développement Debian dont il serait grand temps de reconnaitre qu'il est mauvais...pour le bien de la distribe !!!!D'ailleurs avant la 3.0 il n'y avait que très peu d'archi supporté et c'était déjà aussi lent et peu réactif.
              • [^] # Re: Debian ?

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

                Bon, j'ai l'impression d'entrer dans le troll, mais bon, on est la pour ca ;-)

                Debian est, d'apres des avis divers, la meilleur distrib sur PPC (comprendre à jour et qui marche vraiment bien niveau installation et configuration). J'ai jamais testé Debian sur PPC, mais ca a l'air d'etre au moins une des seul distribs utilisables (gentoo, mdk (a la boure), yellow dog (a la boure), SuSE).

                Debian marche également tres bien sur SPARC (testé moi-meme, et c'est vachement pratique d'utiliser les meme outils et packages lorsqu'on installe sur une archi inconu).

                Toutes les archis que j'ai testé (à part un RS/6000 qui arrive meme pas a booter le CD d'AIX, dc Debian est excusé) marchent tres bien, donc si c'est vraiment la verité, prouve le.
                • [^] # Re: Debian ?

                  Posté par . Évalué à 2.

                  > yellow dog (a la boure)

                  yellow dog 4.0 rc2 est sorti il y a 2 semaine. La final ne va pas tardé.
                  C'est basé sur Fedora Core 2 et donc assez à jours.
                • [^] # Re: Debian ?

                  Posté par . Évalué à 1.

                  Oui je te le prouve : Debian PPC est une horreur, c'est tellement formidable que d'abord ça ne boot pas, puis tu te rend compte en lisant des tonnes de doc que ce n'est pas la bonne version de yaboot par défault mais que la bonne version est présente surt le CD et donc tu dois aller dans l'open-firmware pour faire booter dessus avec une super ligne de commande ésotérique....et puis après de toute façon rien ne marche...Alors qu'avec la Yellow-Dog tout marche nickel ou presque, alors quand tu dis que la Debian cartonne et que le YD est à la bourre heureusement que tu précises que tu n'as pas testé, mais il rest que la vérité est tout le contraire.
                  Quand à la version HPPA qui plante définitivement en pleine installe, la version MIPS qui ne reconnait aucun matos etc....Merci ça vaut vraiment pas le coup, à ce compte là j'utilises une slack en X86, une YD en PPC et NetBSD sur toutes mes archis ésotériques. Mieu vaut des trucs qui font pas tout mais le font bien qu'une Debian qui fait tout mal, mais ce n'est que mon avis.
                  • [^] # Re: Debian ?

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

                    Mmmm...

                    J'avais un copain qui avait un ibook (ceux en plastique) et seul Debian Woody arrivait à booter, YD, y'avais rien a faire, mdk, pareille. C'etait y'a 2 ans quand meme, je precise.

                    Pour HPPA et MIPS, aucune idée. Mais bon, pour MIPS qui ne reconnait aucun matos, ca m'etonne pas si tu parles de l'installateur de woody : il détecte rien. La detection automatique est par contre de niveau beaucoup plus élevé avec le debian installor de la futur sarge, donc a tester pour ces archis (testé pour ix86, pas pour les autres, mais a priori, de gros progrès pour PPC).

                    Apres, Debian est loin d'etre parfait, tu fais comme tu le sens, mais c'est un bon choix pour certains.
                    • [^] # Re: Debian ?

                      Posté par . Évalué à 3.

                      Je pense fondamentalement du bien de plein de choix Debian : la communauté démocratique, le support multi-architecture...par contre j'ai du mal à comprendre que ces personnes s'entêtent dans leur modèle de développement foireux qui pénalise tout le monde; je trouve ça vraiment dommage, c'est un énorme gâchi...et de plus je ne supporte pas les fans Debian qui soutiendront mordicus que leur modèle de dev est excellent alors qu'e c'est LA chose exécrable de cette distribe.
                      • [^] # Re: Debian ?

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

                        A mon avis, le model stable/testing/unstable (c'est ca que tu critique?), en tout cas, il fait se preuves.

                        Il y a peut-etre un probleme sur la politique de "on fait pour toute les archis en meme temps", mais j'ai beau voir les problemes que ca cause, je ne vois pas de meilleurs solutions allant vers des résultats de meme facture et de meme rendement.
                      • [^] # Re: Debian ?

                        Posté par . Évalué à 6.

                        Au contraire, vu le nombre de distribution basée sur Debian, et qui ne s'intéresse ni à la communauté, ni au support multi-architecture, c'est bien aussi son système de développement et de packaging qui intéresse.

                        C'est en tout cas un système original:

                        Debian c'est une machine à fabriquer une distribution de manière quasi-automatique. D'un coté, on alimente en logiciel et à l'autre bout on récupère une distribution très stable. Après l'utilisateur avancé, à le choix de se connecter à cette machine en différent point: stable, testing, unstable (sans compter oldstable, experimental et incomming). Suivant le point ou l'on se connecte sur le système Debian, on va avoir des avantages et inconvénients différents. Et il y a des différences _énormes_ (et plusieurs années d'écart...) de chaque coté du « tube » Debian.

                        Un des (nombreux) avantages, pour le simple utilisateur, c'est de n'avoir à installer un système d'exploitation qu'une seule fois: à l'achat d'une nouvelle machine. Grace au point d'ancrage « testing » du système Debian, il pourra avoir des logiciels raisonnablement récent et raisonnablement stable en même temps.

                        Voilà mon avis utilisateur pour son systeme de développement, mais Debian à bien d'autres avantages/particularités dans d'autres domaines.
                        • [^] # Re: Debian ?

                          Posté par . Évalué à 2.

                          Debian c'est une machine à fabriquer une distribution de manière quasi-automatique

                          Pas compris.

                          il pourra avoir des logiciels raisonnablement récent et raisonnablement stable en même temps.

                          Stable, mais sur quoi tu te bases pour dire ça?

                          Tous les softs que "j'emerge" - et souvent je prend la version que portage* ne met pas par défaut - ne rendent pas mon système directement inutilisable et ne cassent pas à tout va... et très rare sont les paquets critiques, à vous entendre/lire on a l'impression que l'installation d'un paquet récent - encore une fois non officialisé Debian - agirait comme un virus qui contaminerait toute la distro. Faut arrêter les légendes urbaines là :)
                          précision: je ne parle des CVS.

                          *Portage: à sa manière, lui aussi "certifie" la version à utiliser tout en étant suffisament à jour.

                          Voilà quoi! à la lecture - forte intéressante - de vos différentes interventions, je n'ai pas encore trouvé de réel justification à cette engouement Debianeux, si ce n'est qu'elle fait gagner du temps sur celui de la compile et encore pour une version désuète du paquet. Ce n'est pas un mal je tiens à le signaler, on n'a pas besoin d'upgrader à chaque release, mais le LL avançant très vite, j'accèpterai mal d'être à la masse personnellement.



                          merci
                          • [^] # Re: Debian ? reformaté

                            Posté par . Évalué à -3.

                            Debian c'est une machine à fabriquer une distribution de manière quasi-automatique

                            Pas compris.

                            il pourra avoir des logiciels raisonnablement récent et raisonnablement stable en même temps.

                            Stable, mais sur quoi tu te bases pour dire ça?

                            Tous les softs que "j'emerge" - et souvent je prend la version que portage* ne met pas par défaut - ne rendent pas mon système directement inutilisable et ne cassent pas à tout va... et très rare sont les paquets critiques, à vous entendre/lire on a l'impression que l'installation d'un paquet récent - encore une fois non officialisé Debian - agirait comme un virus qui contaminerait toute la distro. Faut arrêter les légendes urbaines là :)
                            précision: je ne parle des CVS.

                            *Portage: à sa manière, lui aussi "certifie" la version à utiliser tout en étant suffisament à jour.

                            Voilà quoi! à la lecture - forte intéressante - de vos différentes interventions, je n'ai pas encore trouvé de réel justification à cette engouement Debianeux, si ce n'est qu'elle fait gagner du temps sur celui de la compile et encore pour une version désuète du paquet. Ce n'est pas un mal je tiens à le signaler, on n'a pas besoin d'upgrader à chaque release, mais le LL avançant très vite, j'accèpterai mal d'être à la masse personnellement.



                            merci
                          • [^] # Re: Debian ?

                            Posté par . Évalué à 1.

                            Je suis en rawhide (Fedora) et j'ai aucun problème.
                            On me dit dans mon oreillette que RedHat va fermer rawhide car ça fait trop concurrence à RHEL.
                            Il y a plein de personnes qui pourront t'affirmer que cooker de Mandrake est rock solide.
                            Unstable de Debian porte mal son nom.
                            Linux 2.6.0 était aussi solide qu'un 2.4.21.

                            > les légendes urbaines

                            C'est quoi ?
                          • [^] # Re: Debian ?

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

                            Debian c'est une machine à fabriquer une distribution de manière quasi-automatique

                            Pas compris.


                            Je pense qu'il parlait du fait que pleins de distributions sont basées sur Debian (Knoppix et dérivé, Linspire, corel...)

                            il pourra avoir des logiciels raisonnablement récent et raisonnablement stable en même temps.

                            Stable, mais sur quoi tu te bases pour dire ça?


                            Un package dans testing à été testé pendant 2 à 10 jours sans bugs majeurs avant son passage dans testing. Ca garantie un certain test préalable du package avant utilisation. Il arrive qu'il y ait quelques bugs genant dans testing, mais ca reste exceptionnel et pour les packages posant des problème (KDE par exemple à eu des problèmes lors d'un changement de version, ce qui à bloqué l'installation de KDE pendant quelques moins, mais l'utilisation des packages d'unstable permettait d'avoir quand meme un KDE).

                            Perso, dans Debian, j'aime la philosophie, la démocratie, debconf, apt-get et dérivé, la mise a jour réguliere des dernieres versions (sauf pour gros packages comme X, KDE, Gnome).
                          • [^] # Re: Debian ?

                            Posté par . Évalué à 3.

                            « > Debian c'est une machine à fabriquer une distribution de manière quasi-automatique

                            Pas compris. »



                            http://www.debian.org/devel/testing(...)

                            Comment fonctionne « testing » ?

                            La distribution « testing » est une distribution générée automatiquement. Elle est générée à partir de la distribution « unstable » par un ensemble de scripts [...]



                            « à la lecture - forte intéressante - de vos différentes interventions, je n'ai pas encore trouvé de réel justification à cette engouement Debianeux »

                            Tu devrai relire, car apparement tu as du sauter des passages. Tu devrais surtout faire un tour, au moins une fois, sur le site de Debian, pour savoir ce que veulent dire « Stable », « Testing » et « Unstable ». Je me permettrais pas de critiquer Gentoo, car je ne la connais pas.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à 1.

                    Je serais curieux de connaitre quel machine PA-RISC tu as utilise pour tester ta Debian... Note que Linux n'est pas supporte sur toutes les machines PA-RISC.
                • [^] # Re: Debian ?

                  Posté par . Évalué à 1.

                  j'ai mis une gentoo sur un powerbook g3 sans aucun problème.
                  ca marche bien, ya pas mal de paquets et je trouve qu'elle est quasi équivalente à la version x86. L'avantage est pour les paquets très récents.
                  Je n'ai pas tenté la debian dessus, mais je pense qu'elle doit etre pas mal aussi.
                  Après on pourra toujours trouver des gens pour défendre becs et ongles telle ou telle distribution. je ne pense pas que dire que debian est la meilleure sur cette plate forme soit vrai ou même constructif.
                  • [^] # Re: Debian ?

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

                    heu, j'ai jamais dit que c'etait LA distribution pour PPC. J'ai juste dit qu'on m'avait dit qu'elle etait bien. De plus, à l'époque, gentoo PPC n'existait pas, dc bon...
            • [^] # Re: Debian ?

              Posté par . Évalué à 6.

              Combien de distribution supporte un serveur X sur 11 architectures différentes en simultanée? A ma connaissance; seule Debian, et de loin.

              Bon, d'accord, Gentoo ne supporte que 10 architectures pour le serveur X, mais au moins, c'est plus rapide que la Debian pour avoir la version en stable.

              Pour les Saint-Thomas, voici le lien :
              http://packages.gentoo.org/search/?sstring=xorg-x11(...)
              • [^] # Re: Debian ?

                Posté par . Évalué à 3.

                c'est plus rapide que la Debian pour avoir la version en stable.

                Tout dépend de ce qu'on appelle stable. Gentoo compile tous les logiciels avec les options de compilations choisies. Si tu n'a pas activé les mêmes options que ton voisin tu peux facilement te retrouver avec des bugs présent uniquement chez toi car personne ne peut tester toutes les possibilités de combinaisons d'options.
                • [^] # Re: Debian ?

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

                  Oui, enfin la theorie du compilateur, c'est que les options d'optimisations affectent la vitesse d'execution mais pas le resultat en lui-meme. Dans quelques cas, c'est vrai que si tu utilises -fmachin -fbidule -O27 -archoptimise-a-more , tu peux avoir quelques instabilites que n'a pas celui qui compile en -O2, mais ca ne va pas tres loin.

                  On n'est pas du tout dans la situation que tu as l'air de decirre, ou chaque mec a des options de compile differentes et obtiens un resultat stable differamment.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à 5.

                    Je ne parlais pas seulement des optimisations mais surtout des USE machin. Avec des paquets binaires tout le monde utilise exactement le même paquet avec les même fonctionnalités activées. Avec une compilation aux petits onions tu peux avoir des bugs qui n'apparaissent pas chez les autres parce que le logiciel a été compilé chez toi avec un --enable truc ou --without machin différent.
                    • [^] # Re: Debian ?

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

                      Ah, je ne comprenais pas.

                      Un autre probleme de la gentoo, c'est qu'elle evolue tres vite et que j'ai parfois des compilations qui foirent, parce que le developpeur a teste avec un systeme parfaitement a jour alors que j'ai quelques versions de retard.
          • [^] # Re: Debian ?

            Posté par . Évalué à 6.

            «Tu ne parles de Debian stable mais de la version de développement de Debian.»

            Idem pour les gens qui disent "aah c'est déjà dans Cooker" à chaque fois qu'une sortie est annoncée... Si j'ai bien compris, Cooker c'est la version "de développement" de Mandrake.

            «À cause de cela, combien de nouveaux venus sont supris de voir que leur Debian est à la traîne et qu'ils doivents passer à la version de développement de Debian pour en bénéficier !»

            Les gens qui utilisent Debian stable sans connaître la différence entre les différentes versions se sont probablement trompés de distribution, de toutes façons.

            Comment prouver que Debian c'est de la merde:
            - Je veux les logiciels les plus récents
            - J'exclus la version de Debian qui comporte les logiciels récents
            - Les versions qui restent ne comportent pas les logiciels récents
            - Debian suxor.

            Il y a plusieurs version de Debian, il faut choisir celle qui convient à ses besoins. (Je ne cherche pas à débattre de ce qui est bon pour un nouveau venu, puisque je ne fais que répondre à celui qui demande pourquoi "on" a choisi Debian.)

            «comment peut-on donc expliquer les multiples trolls, demandes, requêtes, plaintes à propos de l'intégration prochaine de tel ou tel paquetage dans Debian ici et là.»

            Expliquer les trolls c'est facile, donc je ne vais pas te faire cet affront. Plus le reste, je maintiens que les paquets arrivent souvent rapidement. Les plus grosses lenteurs sont sur des paquets gros et compliqués, comme X ou KDE, et manque de pot ce sont ceux là que les gens sont les plus pressés d'avoir, donc forcément ça fait gueuler, mais c'est plutôt rare. Après, tout dépend de ce qu'on attend niveau rapidité. Pour moi un niveau acceptable, c'est entre trois jours et un mois (sauf en cas de correction de faille de sécurité).

            «Enfin, Debian est la seule distribution populaire à encore utiliser XFree86»

            Je ne vois pas le problème... la version utilisée est libre, non ? Le plaisir de changer pour changer, je n'y crois pas trop, mais par contre je suis persuadé que les versions de XFree86 avec la licence qui fait tellement parlé d'elles ne seront pas intégrées.
            • [^] # Re: Debian ?

              Posté par . Évalué à 0.

              Après, tout dépend de ce qu'on attend niveau rapidité. Pour moi un niveau acceptable, c'est entre trois jours et un mois (sauf en cas de correction de faille de sécurité).
              Perso aucune distro ne me convient actuellement, parce que pour moi, rapide = 2 jours maxi !
              • [^] # Re: Debian ?

                Posté par . Évalué à 5.

                --> LFS
              • [^] # Re: Debian ?

                Posté par . Évalué à 4.

                Tu fais donc partie de la horde qui downloader fous qui pourrisent les ftp à la sortie de la dernière version de la distro à la mode. Question : C'est pour faire quoi ? En as tu vraiment besoin ? Ou as-tu peur de mourir de honte si ton voisin a récupéré la dernière version cvs de mplayer avant toi (syndrome moi-j-ai-la-plus-grosse) ?
                • [^] # Re: Debian ?

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

                  Le serveur X est quand même le logiciel/programme qui se prête le mieux au blending-edge.
                  Je m'explique ...

                  Je suis possesseur d'une ATI RADEON 9000 ... alors attendre près d'un an que Xfree 4.3 entre dans SID c'était long, on fait quoi alors ? On met les pilotes proprio, on reste en mode Vesa ? On change de distribution ?

                  Aujourd'hui c'est pareil ... apparement (enfin au vu des changelog) X.Org a intégrer énormement de modifications pour les RADEON, je me repose la question .... je fais quoi ?

                  C'est pas seulement pour avoir la "plus-longue", c'es aussi pour pouvoir utiliser son matériel.

                  Jérôme.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à 1.

                    Je suis possesseur d'une ATI RADEON 9000 ... alors attendre près d'un an que Xfree 4.3 entre dans SID c'était long, on fait quoi alors ? On met les pilotes proprio, on reste en mode Vesa ? On change de distribution ?

                    Moi aussi, mon matériel n'était pas compatible (GEforce 4200), mais j'ai utilisé le package Xfree 4.3 (architetcure i386) de Debian experimental pendant 6 mois sans problèmes.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à -7.

                    Debian ne vise pas "blending-edge".
                    Il ne faut pas acheter du matériel "blending-edge" si on veut une debian. Sinon, changer de distribution. C'est ton matériel qui a un "pb", pas Debian.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à 3.

                    . alors attendre près d'un an que Xfree 4.3 entre dans SID c'était long, on fait quoi alors ?

                    Je ne parlais pas de ce genre de délai. Je réagissais au post de D.Pierre pour qui 2 jours pour avoir la dernière version d'un soft est inacceptable. Ca me parait un peu exagéré.

                    Pour les paquets qui se font attendre dans Debian, il y a toujours les paquets non officiels. Ce que j'aime bien chez Debian c'est qu'il y a des outils bien foutus pour se faire ses propres paquets.
                    Au fait tu lui reproche quoi au driver Radeon actuel? J'ai une Radeon 9200 qui tourne très bien.
                    • [^] # Re: Debian ?

                      Posté par . Évalué à 1.

                      Je ne parlais pas de ce genre de délai. Je réagissais au post de D.Pierre pour qui 2 jours pour avoir la dernière version d'un soft est inacceptable. Ca me parait un peu exagéré.
                      Ha tu avais compris ça ???
                      je me cite : Perso aucune distro ne me convient actuellement, parce que pour moi, rapide = 2 jours maxi !
                      J'ai pas dit que plus de deux jours est inacceptable ! J'ai juste dit que rapide c'est deux jours.
                    • [^] # Re: Debian ?

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

                      Au driver radeon de Xfree 4.3 rien ... bien au contaire !

                      Par contre le support des ATI radeon >= 8500 ne s'est fait qu'avec Xfree 4.3, avant c'était soit le pilote ATI (proprio), soit le pilote vesa.

                      Donc entre février 2003 (http://xfree.org/xnews/#release43(...)) et 18 février 2004 (http://necrotic.deadbeast.net/xsf/XFree86/NEWS.xhtml(...)) (date d'entrée de Xfree 4.3 dans unstable) pas de support réel de ces cartes sur Debian, cekla fait quend même prés d'un an, on est loin des 2 jours de D. Pierre.

                      Bien sûr il existe les dépôt "sauvages" ... en l'occurence il y avait ceux de Daniel Stone qui ont accouché de la version présente dans unstable.

                      Ils sont entrés dans experimental en décembre 2003 (9 mois aprés la sortie).


                      Jérôme.
                  • [^] # Re: Debian ?

                    Posté par . Évalué à 1.

                    alors attendre près d'un an que Xfree 4.3 entre dans SID c'était long

                    Ce n'est pas parce que Debian propose un systeme de packages bien fait qu'on ne peut pas compiler soi-meme ses propres applis.

                    Si tu as vraiment besoin de la derniere version d'un logiciel, rien ne t'empeche d'aller recuperer les sources et de le compiler toi meme.

                    Puis comme dit Croconux, il existe des outils pour creer des paquets Debian assez facilement. Je veux dire par la qu'il y a des gens qui proposent des packages non-officiels (Christian Marillat pour Mplayer par exemple). Ca doit aussi exister pour XFree.

                    Bref, ce n'est ps parce que la derniere version d'un logiciel n'est pas dispo dans les paquets officiels que techniquement, on ne peut pas l'installer. Quand on veut, on peut. Mais ca demande un peu plus de boulot que 'apt-get install mon-paquet'.
                • [^] # Re: Debian ?

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

                  Euh, la curiosite envers un truc qu'on aime ?
                • [^] # Re: Debian ?

                  Posté par . Évalué à 8.

                  la horde qui downloader fous qui pourrisent les ftp
                  Non, je vais juste voir régulièrement sur les FTP les dernières versions de mes logiciels favoris (OpenOffice 1.9, mozilla (nightly)...)
                  à la sortie de la dernière version de la distro à la mode
                  Raté, pour les distros, je préfère bittorrent :)
                  Question : C'est pour faire quoi ?
                  Pour KDE 3.3 : je voulais le tester, apporter mon aide via des rapports de bugs !
                  Et puis, kdepim 3.3 est vraiment un plus !
                  Pour Firefox : me préparer aux changements, pour pouvoir prévenir mes amis de ce qu'ils vont avoir...
                  En as tu vraiment besoin ?
                  J'essaie d'aider le libre, donc je teste les versions beta... J'ai pas le droit ?
                  Ou as-tu peur de mourir de honte si ton voisin a récupéré la dernière version cvs de mplayer avant toi
                  Non. Tu comprends pas.
                  Je programme pas (encore ?) assez bien pour participer à KDE ou GNOME. Je suis pas trop fort en traduction (j'ai essayé de filer un coup de main pour KDE 3.3). Par contre, tester un logiciel, ça me pose pas de problèmes !
                  Qui essaye OOo 1.9 ? Qui rapporte des bugs à son propos ?
                  Qui essaye Looking Glass ? Qui donne des wishlists ?
            • [^] # Re: Debian ?

              Posté par . Évalué à 1.

              Pas d'accord

              X.org n'est pas très long à compiler. D'ailleurs, X.org comporte moins de code bloatted que son prédécesseur. Les plus longs c'est effectivement Gnome et KDE. Ce dernier peut me prendre plus de 10 heures.
          • [^] # Commentaire supprimé

            Posté par . Évalué à 1.

            Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Debian ?

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

            Debian est la seule distribution populaire à encore utiliser XFree86
            OpenBSD utilise encore XFree86 aussi et ça ne va pas encore changer pour la prochaine version (3.6 le 1/11). Bon c'est pas une distribution Linux et c'est pas aussi populaire que Debian et il n'y a pas autant de paquets mais ils supportent quand même 12 architectures (+2 en développement actif).

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: Debian ?

              Posté par . Évalué à 3.

              Et puis surtout...qui utilise un serveur X sur sa machine OpenBSD?
      • [^] # Re: Debian ?

        Posté par . Évalué à 3.

        > mais quel est l'intérêt d'une Debian?

        Je n'utilise pas Debian.
        Mais Debian est une distribution vraiment à part dans le logiciel libre et en même temps complètement dans le logiciel libre.

        C'est l'une des distributions qui contribue le plus au logiciel et ça profite à tout le monde. Son influence est indéniable.

        Lorsque Debian annonce passer à Xorg (ils étaient parmis les premiers et les premières annonces ont été si proches qu'il faut une photo finish pour les départager), même si Xorg n'est pas dans la branche stable la semaine suivante, ça fait rapidement des développeurs/auditeurs/testeurs/traducteurs/... de plus.
        Ce n'est pas une distribution pour envoyer un SMS avec :

        - "kikou, suis sous KDE 3.3.x avec transparence."
        • [^] # Re: Debian ?

          Posté par . Évalué à -4.

          >Ce n'est pas une distribution pour envoyer un SMS avec :
          > - "kikou, suis sous KDE 3.3.x avec transparence."

          perso, j'envoie d'autres messages à mes ami(e)s ke le n° de version de mon kde ;)
      • [^] # Re: Debian ?

        Posté par . Évalué à 3.

        Tu sais, les goûts et les couleurs...
        Moi aussi, je n'installe que des Slackware, c'est la distribution que je maîtrise le mieux et je n'ai eu que des galères avec les gestionnaires de packages qui "gèrent" les dépendances.
        Mais bon, c'est moi. quelqu'un qui préfère avoir un système de gestion de packages avec dépendances sera bien mieux servi par Debian que par la Slack. Et il y a plus de packages disponibles, en général bien validés par beaucoup d'utilisateurs, alors pour beaucoup d'administrateurs, c'est plus sur que de se compiler son serveur soit même avec sa Slack.
        Enfin bref, chacun trouve ce qui lui plait et c'est très bien comme ça.
        Et ça n'a rien à voir avec Xorg.

        Richard
      • [^] # Re: Debian ?

        Posté par . Évalué à 2.

        mais quel est l'intérêt d'une Debian?
        N'avoir a réinstaller le système que si ton HD tombe en rade. Sinon, le système évolue un peu tous les jours.
  • # [HS] fd.o release 1.0 ?

    Posté par . Évalué à 2.

    Tiens, dans l'article d'Ars Technica (fin 2ème page), ils parlent de la plateforme 1.0 de freedesktop.org.
    Ca m'a intrigué, alors j'ai googlisé, mais je n'ai trouvé qu'un petit lien [1] qui se battait en duel contre un autre encore plus vieux[2].

    C'est pauvre. Vous avez d'autres infos?
    Et puis c'est quoi, exactement cette plateforme 1.0 ? (à part une collection de bibliothèques pour X ;)
    Et dernière question : c'est quoi un ISV ?

    [1] : http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg0057(...)
    [2] : http://lists.gnome.org/archives/desktop-devel-list/2004-January/msg(...)
    • [^] # Re: [HS] fd.o release 1.0 ?

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

      Si tu regardes la vidéos Freedesktop de aKademy, ils parle de freedesktop 1.0 qui va sortir dans quelques jours(avec X.Org). Mais j'ai eu beaucoup de mal a comprendre le monsieur donc si quelqu'un a vu la video et peu nous en dire un mot :)
    • [^] # Re: [HS] fd.o release 1.0 ?

      Posté par . Évalué à 5.

      En gros, c'est ensemble de spécifications et de logiciels parmi ceux présents sur freedesktop.org qui sont considérés comme étant "prêts" (mature, implémentés, diffusés). C'est pour permettre aux ISV (cf ci-dessous) et aux développeurs libres de savoir sur quelles technologies ils peuvent s'appuyer pour bâtir les applications bureaux de demain.

      Les détails, on les aura dans quelques jours.

      ISV : Independant Software Vendor
      http://www.google.com/search?q=define%3AISV&ie=UTF-8&oe=UTF(...)
  • # Démo live

    Posté par . Évalué à 4.

    Alors si vous voulez voir une démonstration des fonctionnalités de ces extensions, vous pouvez tester Looking Glass (we need you : test it !)
    C'est relativement simple (https://lg3d.dev.java.net(...)) et puis c'est juste une fenêtre à ouvrir :)
    On demande juste un test en mode fenêtré (lancer uniquement 2 applis Java de démo) et mode plein écran si vous pouvez (vous devez quitter votre X "normal") : le plein écran ne permet pas de lancer de nombreux programmes (enfin, les derniers CVS sont corrects) mais c'est un bon test
    En gros, LG utilise un X.org patché (lourdement ?) et donc ne tournera pas sur un X.org "normal" pour l'instant, néanmoins les devs négocient l'intégration de ces patchs dans X.org
    • [^] # Re: Démo live

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

      Je suis heureux des projets libres soutenus par Sun, comme par exemple OpenOffice, mais je ne vois pas comment pourrait s'intégrer des composants Java dans un bureau libre alors qu'il n'existe pas à ma connaissance de machine Java performante et libre ?

      A mon humble avis X11 n'a bas besoin d'une machine virtuelle occupant plus de 20 méga de mémoire et de code Java, mais d'une refonte de son architecture.

      L'intiative du projet Looking Glass est intéressante, c'est une belle démo.
      • [^] # Re: Démo live

        Posté par . Évalué à 6.

        Je crois que comme beaucoup de monde tu vois mal ce que représente LG3D.
        LG3D deviendra un environnement 3D complet, gestionnaire de fichiers en 3D, login en 3D... Oui, ça bouffe de la RAM, oui ça bouffe du CPU... Mais le but n'est pas d'économiser du matériel ! c'est d'expérimenter le bureau 3D, avec des applications 3D. C'est plus qu'un gestionnaire de fenêtres, il se rapprochera plus de KDE/GNOME...
        Donc c'est un lieu d'expérimentations, mais aussi une vitrine technologique et un environnement utilisable (enfin pas pour l'instant)...
        • [^] # Re: Démo live

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

          Ok, autant l'environnement 3D oui, le gestionnaires de fichiers 3d, pourquoi pas... mais un login en 3D c'est quoi ? Et surtout à quoi cela peut bien servire ? Avoir une démo 3D avec de l'alpha blending et des "Access denied" qui volent partout suite à une typo dans le mot de passe ?

          LG3D c'est très bien pour ce que cela doit être... un concept. Exactement comme les constructeur de voiture font des concepts cars que personne ne conduira tel que mais qui sont bourrées de bonnes idées.

          D'ailleurs Apple semble peut-être déjà s'inspirer de LG3D puisque le prochain OS X Tiger intégrera un truc appelé "Dashboard". Peu importe l'intérêt du truc, le fait est que l'on peut "retourner" une fenêtre pour en modifier les propriétés. Quelque chose que je crois bien avoir vu dans une vidéo de présentation de LG3D...

          Ceci dit le concept de bureau 3D semble intéressant. cela fait toujours une dimension de plus pour stocker des infos.
          • [^] # Re: Démo live

            Posté par . Évalué à 1.

            Ok, autant l'environnement 3D oui, le gestionnaires de fichiers 3d, pourquoi pas... mais un login en 3D c'est quoi ? Et surtout à quoi cela peut bien servire ? Avoir une démo 3D avec de l'alpha blending et des "Access denied" qui volent partout suite à une typo dans le mot de passe ?
            Pour que l'utilisateur se retrouve face à un truc simple à comprendre, avec une bonne représentation du changement d'utilisateur ? Enfin, c'est ce que j'ai compris des discussions....
      • [^] # Re: Démo live

        Posté par . Évalué à 3.

        Croquet semble autrement plus intéressant et ambitieux que Looking Glass AMHA : http://www.opencroquet.org/index.html(...)

        Je me suis abonné à la ML en attendant une release utilisable qui semble être prévue ces jours-ci...
  • # Perso je ne retiendrai qu'une seule chose du plan de travail

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

    * Merge Mach64 DRI support (Eric Anholt, July 23)

    Youpi youpi! Avec l'intégration du support Xv dans la dernière branche, ça veut dire que je vais bientôt pouvoir directement utiliser des releases officielles!

    OK, c'est peut-être un détail pour vous, mais pour moi ça veut dire beaucoup ;)
  • # Re : Les nouveautés du prochain X11R6.8

    Posté par . Évalué à 4.

    > Le groupe freedesktop.org est sur le point de sortir une nouvelle version de X11, qui s'appellera X11R6.8

    C'est X.org. Ce n'est pas freedesktop. Par contre freedesktop héberge le développement de X.org .

    Pour info, la fondation X.Org :
    http://www.x.org/(...)

    Et oui, X.Org n'est pas que pour les bureaux libres (free desktop:-)).
    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

      A je te tiens en train de parler de freedesktop :p

      Tu m'as tellement pris la tete la derniere fois que j'ai pas insisté.
      Comme ca fait une semaine que il y'a une discution sur les ml gstreamer/amarok/kde-multimedia/NMM/MAS pour savoir quel framework multimedia choisir pour Kde et apres confirmation des developpeurs de amarok qui ont commencé a essayer MAS, TU AVAIS TORD.

      MAS comme ARTS est un framework multimedia(audio seulement) et un serveur de son. Il fait les deux à la fois! En clair, la derniere fois, tu nous a pris la tete pour rien. Alors avant de dire que les gens n'ont rien compris, il faudrait peut etre te demander si toi tu as compris :p Donc oui j'avais raison de comparer mas et gstreamer :p

      Idem pour cette fois ci, lors de la conf à l'aKademy, X.Org a bien été montré comme faisait partie du projet freedesktop! De plus, ne pas confondre X.org avec X.Org. Le projet n'est pas celui de la fondation X.org, il est soutenue par cette derniere par contre. Mais ce que tu reprends est juste, freedesktop 1.0 est sur le point de sortir X11R6.8 comme cela a été dit a l'aKademy.

      Cordialement :p
      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

        Posté par . Évalué à 3.

        > Tu m'as tellement pris la tete la derniere fois que j'ai pas insisté.

        Pardon ?

        > X.Org a bien été montré comme faisait partie du projet freedesktop!

        Et ?
        X.org est un projet comme pkgconfig. Il fait partie de freedesktop mais freedesktop n'est pas le mainteneur de X.org. Ça me semble claire.

        freedesktop héberge utf-8 :
        http://www.freedesktop.org/Software/utf-8(...)
        utf-8 est maintenu par freedesktop ?

        > freedesktop 1.0 est sur le point de sortir X11R6.8

        Non.
        C'est comme dire :
        - LSB 1.3 est sur le point de sortir libc v2.2 et Linux 2.2
        ou
        - Mandrake est sur le point de sortir X.org 6.8.0

        X11R6.8 fera parti de freedesktop 1.0.
      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

        Posté par . Évalué à 4.

        le site de X.org renvoie directement à freedesktop pour le source et autre informations
        Les personnes travaillent sur le CVS X.org de freedesktop ou nommé explicitement sur X.org sont les même.
        X11R6.8 de X.org ou, si vous préférez, freedesktop.org est la même chose.

        Freedesktop héberge une foule de projets servant à faire un "desktop libre" et donne des facilités (cvs etc )

        il y a aussi xserver/kdrive etc, qui est manifestement devenu un fork expérimental pour tester extensions et future modèle de driver pour une hypothetique version de X11 par X.org (et c 'est hébergé sur F.d.o).

        il n'y a pas pour le moment d'organisation structurée et carrée, c'est pour cela que tout cela est encore flou.

        il n'y a pas de commité "freedesktop" qui maintient le code X.org ou Desktop-utils ou pkgconfig.

        il n'y a pas de groupe Freedesktop au sens Comité KDE, Mozilla ou Gnome.

        Quand à comparer MAS et Gstreamer, il y a clairement un problème. Gstreamer est beaucoup plus vaste que MAS et on peut même supposer qu'à terme gstreamer aura un plugin MAS pour l'audio.
      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

        Posté par . Évalué à 3.

        > MAS comme ARTS est un framework multimedia(audio seulement) et un serveur de son. Il fait les deux à la fois!

        Une grosse différence entre MAS et ARTS est que MAS marche aussi via réseau et il faut considérer que tu ne peux pas modifier la partie serveur (comme pour X11).
        Le serveur ARTS, est pour _un_ utilisateur (celui qui vient de se logguer). A l'instar de X11, le serveur MAS est pour toutes les applis clientes qui se connectent au serveur. Le serveur MAS n'est pas lancé lorsque tu te logguent mais à l'initialisation d'X11 (ce n'est pas encore fait mais au final c'est comme ça que le serveur sera lancé).

        Oui il y aura des codecs et quelques effets rudimentaires dans MAS.
        Pourquoi des codecs ?
        Car il faut envoyer et recevoir le son via réseau et donc compresser le son est une bonne idée. Actuellement, il n'y a que le codec mp3 dans MAS ! Et ce codec ne permet pas de coder en mp3 mais uniquement de lire.

        Il y aura aussi AC5.1, ...
        Il y aura un mixer évolué (c'est sur le serveur qu'il y a la carte son...).
        Il y aura sûrement des features qui ne sont pas liées à un serveur de son.

        X11 offre aussi des facilités et il y a eu beaucoup d'applis faitent uniquement avec libX11. Ça n'en fait pas un framework pour faire des applis graphiques.
        Ce n'est pas parce que X11 affiche mon DVD que c'est un framework multimedia.


        > pour Kde

        Tout est là...
        1 - Gstreamer utilise glib.
        2 - Gstreamer à l'origine cible Gnome.
        3 - Dans Gstreamer il y a 'G'.

        Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.

        Mais pour la lecture de video ça va être rigolo. Gstreamer récupère le flux video et audio (forcément), mais KDE va demander à Gstreamer de ne pas envoyer le flux audio à MAS (ce que peut faire Gstreamer). KDE va récuper le flux audio pour l'envoyer à MAS.
        Un peu bordélique.

        Ou KDE vire Gstreamer et utilise Xine qui utilisera MAS (bref comme Gstreamer le fait).
        Quoiqu'il en soit, pour la video MAS ne sera utilisé que comme un serveur son.

        > TU AVAIS TORD

        KDE ne pense pas la même chose que Gnome (ou plus spécifiquement Gstreamer) qui considère MAS comme un serveur de son.
        KDE ne voit pas MAS et Gstreamer de la même façon que freedesktop :
        * GStreamer is a streaming media framework.
        * Media Application Server™ (MAS®) is a network transparent streaming media server.

        Je ne veux pas me battre avec toi (utilisateur kde?) :
        KDE a raison, les autres tords (dont moi) et ils ne font que troller.

        Il y a quelques temps, KDE se plaignait de la lenteur de Gstreamer à intégrer leur patch.
        Je dis : que KDE n'utilise pas Gstreamer alors. Comme ça on aura la paix.
        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

          Posté par . Évalué à 3.

          Non, ARTS aussi marche via le réseau.

          Il n'y a pas (plus ?) de blocage de KDE par rapport à gstreamer et glib, beaucoup en parlent en bien. Vois par exemple ce qu'en dit sur son blog le mainteneur d'Amarok
          http://grammarian.homelinux.net/~mpyne/weblog/kde/gstreamer-huh.htm(...)
          http://grammarian.homelinux.net/~mpyne/weblog/kde/gstreamer-part-de(...)

          Restons calme. KDE va changer de framework multimédia (There is a general consensus among KDE developers that aRts sucks., extrait du dernier KDE CVS-Digest), mais la décision pour savoir le(s)quel(s) n'a pas encore été prise, ce qui n'est pas un drame puisque KDE 4.0 n'est pas pour demain.
          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

            Posté par . Évalué à 2.

            > Non, ARTS aussi marche via le réseau.

            J'ignorais. Mais je ne suis pas le seul :
            http://grammarian.homelinux.net/~mpyne/weblog/kde/gstreamer-huh.htm(...)
            I wasn't even aware that aRts could do this until I saw this point become mentioned

            Ça fait depuis bien longtemps qu'on est dans le registre "j'avance et tu recule, je tourne à droite et je regarde à gauche..." avec gstreamer et KDE.
            Maintenant ça devient pénible.
            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

              Le problème majeur de arts n'est pas ce qu'il ne sait pas faire mais surtout le fait qu'il n'est pas maintenu et que personne ne peut le maintenir.

              Lancez artsbuilder par exemple et vous verrez que arts peut faire des trucs très complexe. Mais personne n'a jamais utilisé artsbuilder et personne ne sait comment ça marche vu le peu de documentation.

              Arts est un framework audio mais ce qu'il faut à KDE maintenant c'est un framewok multimédia si possible indépendant du server de son. Et il y a beaucoup de choix : jack / gstreamer, jack / libxine, MAS / gstreamer, NMM,... ?
              Et encore je ne suis pas sûr que certains des candidats ne font pas aussi serveur de son ou framework multimédia.

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

              Personellement, je trouve tes commentaires assez penible a lire, non pas pour leur contenu, mais parce qu'on dirait que tu t'obstines a ne pas vouloir comprendre ce que disent les autres. C'est comme si tu avais pose un jugement sur les opinions de telle ou telle personne et que tu ne puisses pas envisager qu'il pense autre chose.

              > Trois "bonnes" raisons pour KDE de ne pas utiliser Gstreamer.

              > 2 - Gstreamer à l'origine cible Gnome.
              C'est plus du tout le cas. Et il est aussi tres populaire chez KDE. De toute facon, une appli qui marche est toujours plus populaire qu'une appli qui ne marche pas.

              > 1 - Gstreamer utilise glib.

              J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.

              Ensuite, il faut voir qu'il y a des gens qui n'ont pas glib sur leur PC, tout comme il y a des gens qui n'ont pas Qt sur leur PC. Toute dependance supplementaire n'est _jamais_ bienvenue.

              > "j'avance et tu recule, je tourne à droite et je regarde à gauche..

              On parle et tu refuses d'ecouter, je pense que tu es aussi tres fort a ce jeu.
              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                Posté par . Évalué à -3.

                > je trouve tes commentaires assez penible a lire

                Ne les lit pas.

                > mais parce qu'on dirait que tu t'obstines a ne pas vouloir comprendre ce que disent les autres.

                Lorsqu'on attaque quelqu'un à un niveau presque personnel, il faut être plus précis ou ne rien dire du tout.
                Par exemple tu pourrais dire ce que je refuse de comprendre dans ce que disent les autres. Il faut aussi garder en tête qu'il y a une différence entre comprendre ce que disent les autres (avoir ou non des problèmes de communication/compréhension) et être d'accord avec ce qu'ils disent.
                Je comprends ce que dit gnumdk. D'ailleur, je trouve gnumdk claire et il n'est en rien fourbe ou ambigu. Mais je ne suis pas d'accord avec ce qu'il dit. Et notes bien qu'il n'est pas d'accord avec moi. On est d'accord sur notre désaccord :-)

                > > 2 - Gstreamer à l'origine cible Gnome.
                > C'est plus du tout le cas.

                C'est moi ou c'est toi qui a des problèmes de compréhension ?

                > De toute facon, une appli qui marche est toujours plus populaire qu'une appli qui ne marche pas.

                gnumdk est plus intéressant et je préfère "croiser le fer" avec lui.
              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                Posté par . Évalué à 3.

                > J'ai deja explique pourquoi pour des raisons techniques, ca posait des problemes: il faut traduire toutes les structures de donnees echangees entre glib et KDE et ca a un cout CPU.

                Rire dans la salle :-)
                KDE est cerné de lib en C.
                C'est mieux si c'est déjà en C++ (quoi que...).

                Gstreamer n'est pas une librairie ala libc où une fonction (par exemple strcmp()) peut-être appelé 2 000 000 de fois en une seconde. L'appli fait gst_play() et ça reste dans gstreamer. Il n'y a pas d'aller-retour entre l'appli en C++ et gstreamer qui pénalisent la lecture d'une video. Il doit bien y avoir des "détails" comme ce qui indique la position dans le flux, etc mais ça doit peser moins de 0,002 % de charge cpu.

                Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx = developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.
                Je ne veux pas dire que la glib est parfaite.
                Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly et donc KDE friendly.
                KDE n'est pas C friendly (évidemment y en a un qui va bondir pour indiquer un wrap qt ou kde, mais ces wrap sont immondes (oui oui, j'ai déjà regardé)).

                KDE peut utiliser des bibliothèques C, et plus particulièrement les libs qui utilisent glib et qui peuvent être orienté objet (comme gstreamer). Alors profitez en.

                Que ceci ne t'empêche pas de faire des propositions pour améliorer les performances de la glib.

                > Toute dependance supplementaire n'est _jamais_ bienvenue.

                Tu veux dire quoi ?
                Que lorsque la dépendance à libvorbis a été ajoutée, elle n'était pas la bienvenue ?
                Que tout proposition pour virer la dépendance à Qt est la bienvenue ?


                PS : KDE dépend déjà de la glib (via arts).
                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                  Posté par . Évalué à 2.

                  > Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly et donc KDE friendly.

                  mouais, un peu éxagérer quand même, un modèle objet fait en C, même s'il est aussi bien fait que gobject, reste encore loin d'être "C++ friendly". Enfin c'est un avis perso.

                  Par contre de se que je lis dans les mailling kde, je ne pense pas que se qui bloque l'intégration de gstreamer dans kde soit la dépendance a la glib, même si nombreux trouvent qu'elle fait double usage avec Qt.
                  Ils cherchent amha la lib la plus preformante, avec les meilleurs fonctionnalités et la moin chiantes a coder. Ils sont d'ailleurs actuellement en train de monter un comparatif entre gstreamer, nmm et MAS, et a prioris, après la démo faite a Akademy, ils pencheraient plus vers NMM.
                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                    Posté par . Évalué à 2.

                    > un modèle objet fait en C, même s'il est aussi bien fait que gobject, reste encore loin d'être "C++ friendly"

                    J'adore ton absence totale d'argument.
                    Ah non, il y a un "mouais" et un "c'est un avis perso".

                    Tu connais mieux ? Bash peut-être ?
                    Surtout que tu dis "loin d'être "C++ friendly"".
                    glib est C++ friendly, si tu fais un wrapeur.
                    Faire un wrapeur pour C++ est assez facile et cohérent (tu obtients une librairie objet) avec gobject.

                    Tu es un bon exemple de l'hostilité d'une partie de KDE à tout sauf C++. Un certain intégrisme gratuit, du nombrilisme, du snobisme. de la prétention et du mépris pour les autres.
                      - Désolé MOONNsieur, si la glib ne vous sied pas.
                      - Le compilateur C++ de MOONNsieur est avancé.
                      - Gontrand, mon brave, donnez une double ration de code C aux cochons. nous les mangerons ce dimanche pour fêter ma magnifissance. Et veillez aussi à ce que le bon peuple ne manque pas de code C aussi. Je ne tiens pas à subire une rébellion en ces jours de ripaille.

                    Pour ton information, KDE utilise plus d'une dizaine de librairie que tu pourrais qualifier de loin d'être "C++ friendly" (voire plus).

                    > Ils cherchent amha la lib la plus preformante, avec les meilleurs fonctionnalités et la moin chiantes a coder.

                    Encore...
                    On va dire que c'est le prix de l'exellence.
                    btw, "la moin chiante à coder" est de trop puisqu'ils ne semblent pas parti pour la coder...
                      - Ô grand KDE, veux-tu bien accèpter cette librairie comme preuve de ma soumission ?
                      - Elle est codée en C++ ?
                      - Non mais elle utilise gobject de glib.
                      - Mais quel culot ! Comment oses-tu proposer un trucs si loin être "C++ friendly". Jetez moi ce plouc aux lions.

                    Les temps sont dures et j'ai peur que notre élite C++ soit obligé de bouffer du code C "bon pour les cochons".
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                      Posté par . Évalué à 2.

                      tu ne serais pas un peu succeptible

                      > J'adore ton absence totale d'argument.

                      cest juste une constation, et j'ai toujours trouvé que faire de l'objet dans un langage impératif est d'une stupidité extreme.

                      > Tu connais mieux ? Bash peut-être ?

                      je vois pas le lien, je connais mieu, pour faire de l'objet il y a plein de langage orienté objet.

                      > glib est C++ friendly, si tu fais un wrapeur
                      tout comme n'importe quel lib alors et pas spécialement la glib, même si évidement c'est plus simple avec la glib.

                      > Tu es un bon exemple de l'hostilité d'une partie de KDE à tout sauf C++. Un certain intégrisme gratuit, du nombrilisme, du snobisme. de la prétention et du mépris pour les autres.

                      J'ai juste fais une remarque d'ordre général, qui ne concernait absolument pas kde. Je n'aime pas spécialement le C++, dont je trouve la sytaxe pas top, et aucun compilo qui gère correctement le langage. Je n'ai non plus rien contre la glib que j'utilise sur certain projets. Je faisais juste la remarque en fin de post que certains dev kde trouvent qu'elle fait souvent double emploi avec qt, et je suis assez daccord avec eux.

                      > btw, "la moin chiante à coder" est de trop puisqu'ils ne semblent pas parti pour la coder...

                      je parlai de l'api en fait, change dans mon post par "la moin chiante à utiliser". KDE n'est pas contre gstreamer, il lui trouve des défauts (comme pour les autres kibs dailleurs) qui n'a rien a voir avec l'utilisation de la glib ou du fait qu'elle soit en C, il éxiste dailleurs déjà des kio pour elle. Mais ils veulent juste la meilleure, ensuite qu'on soit daccord avec eux ou pas est une autre histoire, et rien ne t'empêhe de donné ton avis sur les ml.
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                        Posté par . Évalué à -1.

                        > J'ai juste fais une remarque d'ordre général

                        Trouves une lib (non C++ puisque Gtk+/Gnome est en C pour supporter le binding) qui est plus "C++ friendly". Un truc en Java ou C# ? Désolé mais c'est pas la même catégorie.
                        Le développeur KDE qui fait le wrap gstreamer trouve ça facile à réaliser.

                        J'ai vu plus bas : APR, NSPR (j'ignore volontairement openssl).
                        En quoi elles sont mieux ?
                        glib/apr/nspr ont toute été faite en même temps environ (à un an près. glib est plus vieille mais était au début intégrée à gtk+).
                        Il me semble peut probable de voir une nouvelle librairie de ce type.
                        Puis glib est nettement plus utilisée. Non que les autres soit de moins bonne qualité (je ne connait pas nspr). apr est "limité" à apache et subversion (qui utilise aussi apache) et nspr à mozilla.

                        Peuvent-elles supporter la programmation objet pour faire de "joli" binding C++ ?

                        Je sens qu'on va encore me répondre un truc du style "la programmation object est réservé aux élites du C++".
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à 1.

                          Pourquoi ignores-tu openSSL ? Perso je pense que c'est celle qui ressemble le plus a la glib, la crypto en plus, et c'est tout aussi simple de faire de joli binding C++.
                          NSPR était un mauvais exemple, elle a quelque manque (pas entièrement thread safe, pas de gestion des fichiers de configuration...)
                          Apr est largement utilisable en dehors des projets utilisant apache.
                          Et tu verras plus bas pkoi je ne trouve pas que la glib est c++ friendly.

                          Quel est l'interet de faire un binding avec la glib : c'est un ajout de travail qui fait de plus doublon avec ce que déjà le C++. Si c'est pour laisser le choix aux devs pourquoi pas, je pense quand même que c'est une perte de temps vu ce qu'elle apporte par rapport a des framework C++

                          > Je sens qu'on va encore me répondre un truc du style "la programmation object est réservé aux élites du C++".

                          et sur quoi tu te bases pour "sentir" ça ?
                          heureusement qu'il ne faut ni être une élite ni utiliser le C++ pour faire de l'objet.
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à 1.

                            > Pourquoi ignores-tu openSSL ?

                            Parce c'est une lib métier.
                            glib ne sert à rien si j'ose dire...

                            > et sur quoi tu te bases pour "sentir" ça ?

                            La preuve, toi :
                            - "c'est un ajout de travail qui fait de plus doublon avec ce que déjà le C++"
                            - "je pense quand même que c'est une perte de temps vu ce qu'elle apporte par rapport a des framework C++"

                            En gros, la programmation objet si ce n'est pas en C++, c'est doublon ou moins bien et donc inutile.

                            Et puisqu'on est sur les bindings, il est beaucoup plus facile de faire des bindings si la librairie de base est en C qu'en C++.

                            Faire le binding d'une librairie C++ qui utilise tout les fonctionnalités C++ est pratiquement impossible (ou c'est immonde). Pour preuve, les bindings de librairies C++ sont rares ou alors se sont des bindings vers java ou C#.
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                              Posté par . Évalué à -1.

                              > La preuve, toi :
                              - "c'est un ajout de travail qui fait de plus doublon avec ce que déjà le C++"
                              - "je pense quand même que c'est une perte de temps vu ce qu'elle apporte par rapport a des framework C++"


                              et ou ai-je dit que l'object est réservé à l'élite ou au C++
                              il n'y aurait pratiquement aucun projet c++ si on utilisait pas de bindings de lib en c, et je ne parlai pas de programation objet mais des foncionnalités de la glib
                              Néanmoins je ne vois pas l'intéret de reinventer la roue, ou de bloater de partout

                              > Et puisqu'on est sur les bindings, il est beaucoup plus facile de faire des bindings si la librairie de base est en C qu'en C++.

                              > Faire le binding d'une librairie C++ qui utilise tout les fonctionnalités C++ est pratiquement impossible (ou c'est immonde). Pour preuve, les bindings de librairies C++ sont rares ou alors se sont des bindings vers java ou C#.


                              je ne dis pas le contraire, et je suis entièrement daccord la dessus. Pour java je ne sais pas, mais pour C# (enfin pour .net ou mono en général, les bindings doivent être fait en C, qui est "le plus petit dénominateur commun", ce qui est, je pense, en sorte plutot intelligent de leur part).
                              Je ne critiquais pas la possibilitée de faire des bindings, mais leur utilitées
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 1.

                                > Je ne critiquais pas la possibilitée de faire des bindings, mais leur utilitées

                                Je ne sais pas ...
                                Par exemple utiliser gstreamer en C++.
                                Ou utiliser ce sympathique programme en python qui utilise Gnome :
                                http://meld.sourceforge.net/(...)

                                Ou avoir yum qui utilise le binding python de rpm (qui est aussi utilisé par up2date, anaconda, etc).

                                Si tu connais php tu peux faire des applis graphique en php :
                                http://gtk.php.net/(...)

                                J'arrête là car je n'y comprend rien à vos arguments.
                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                  Je ne penses pas que les conversions glib <-> Qt aient un impact majeur dans ce cas precis. Mais il faut penser au contexte general. Si KDE commence a se lier avec glib, quelles vont etre les consequences. Est-ce que d'autres applications vont l'utliiser aussi, etc.

                  > Pour être honnète, je trouve gonflé que certains KDE-xxx (xxx =
                  > developpeurs|fans|utilisateurs...) critiquent la glib dès qu'elle est utilisée dans le cadre de KDE.

                  C'est pas tant la glib elle-meme qui est critiquee que le fait qu'elle fasse doublon avec d'une part la stl, d'autre part la QTL.

                  D'un point de vue personnel, j'admire beaucoup le travail qui a ete fait sur la glib, mais je ne vois pas du tout son interet. Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ? Pourquoi faire du C objet ? Sincerement, j'aime bien coder en C, mais quand je code en C, c'est pas pour faire du C++, c'est pour faire du C. Il y a quand meme une grosse incoherence dans ce choix, qui d'un cote preconise un langage relativement simple et refuse absoluement le C++, et de l'autre cote, s'amuse a refaire un framework objet en C. Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder. On n'en arrive meme a la situation de gtkmm qui wrappe en C++ une lib en C qui emule un comportement objet. Deux niveaux d'indirections !

                  > Mais la glib avec son modèle objet, permet à gstreamer (et Gnome) d'être C++ friendly

                  La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet, ce qui est tres souhaitable pour une appli graphique ou tu manipules des tonnes d'objets.

                  > KDE n'est pas C friendly

                  Non. Et tu sais quoi ? Ca ne manque a personne.

                  > > toute dependance n'est jamais la bienvenue

                  J'aurai de preciser toute dependance qui duplique une fonctionnalite existante. En dehors de l'approche gstreamer, quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?

                  Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.
                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                    Posté par . Évalué à -1.

                    > Mais il faut penser au contexte general. Si KDE commence a se lier avec glib, quelles vont etre les consequences. Est-ce que d'autres applications vont l'utliiser aussi, etc.

                    Tu as lu ce que tu as écrit ?
                    Tu as peur que les gens utilisent leur liberté d'utiliser glib.
                    Dans le contexte LL, c'est fort.

                    btw, il est évident que KDE va mettre en place un wraper.
                    Puis je le répète encore. KDE utilise déjà la glib.

                    > mais je ne vois pas du tout son interet. Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ? Pourquoi faire du C objet ?

                    Je ne comprend pas de voir et revoir et voir encore cet argument. Je n'y reviens pas.

                    > La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet

                    Si tu as mieux (et qui ne soit pas C++), fais signe.
                    Puis quelle incohérence dans ton propos. Tu dis que gobject fait "doublon" avec C++ et après du dit que ce n'est pas C++ friendly. Faudrait savoir.

                    > > KDE n'est pas C friendly
                    > Non. Et tu sais quoi ? Ca ne manque a personne.

                    Raisonnement à la pBpG.
                    Ce n'est pas possible, donc personne en a besoin...
                    Bravo.
                    Pourtant il y a une tentative pour avoir un wrap C ? Non ?

                    > qui n'est parfois pas installee sur des systemes

                    Il faudrait abondonner cet argument ridicule.
                    yum/apt/urpmi/etc existe.
                    Si je regarde kdebase (qui comme son nom l'indique est la base) j'ai les dépendances "bizarres" suivantes :
                    audiofile-0.2.6-1 <= pour esound
                    esound-0.2.35-1
                    glib2-2.4.6-1 <= glib est déjà utilisé
                    libidn-0.5.4-1 <= http://www.gnu.org/software/libidn(...)
                    libraw1394-0.10.1-3
                    lm_sensors-2.8.7-1 <=
                    pcre-4.5-3
                    perl-5.8.5-3
                    samba-common-3.0.6-3

                    perl et samba-common c'est du lourd...
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                      Posté par . Évalué à 2.

                      comme quoi un peu de granularité chez redhat ferait pas de mal , j ai absolument pas tout ce bordel de dependances sur ma cooker...
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                        Posté par . Évalué à 2.

                        > comme quoi un peu de granularité chez redhat ferait pas de mal

                        Moi je m'en fous, mais ça perturbe Philippe Fremy.
                        Et NB, Fedora suit l"organisation de KDE. Un tarball => un paquet (sauf pour -devel).

                        > j ai absolument pas tout ce bordel de dependances sur ma cooker...

                        Tu l'as forcément. Red Hat ne va pas ajouter des dépendances pour le plaisir. Par contre Mandrake "splite" KDE en plus de paquet.
                        Ce qui me dérange en rien aussi.
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                      Posté par . Évalué à 3.

                      > > La glib n'est pas du tout C++ friendly. Elle permet en revanche aux programmeurs gnome de programmer dans un style objet

                      > Si tu as mieux (et qui ne soit pas C++), fais signe.
                      > Puis quelle incohérence dans ton propos. Tu dis que gobject fait "doublon" avec C++ et après du dit que ce n'est pas C++ friendly. Faudrait > savoir.


                      En mieu, ou tout du moin équivalent regarde APR, NSPR, OpenSSL et j'en oubli surement.
                      Il n'y a pas d'incohérence dans son propo, les fonctionnalités de la glib sont en doublon par rapport a la stl et la qtl, c'est dailleurs un des buts de la glib, et ce n'est quand même pas C++ friendly, pas d'itérateur, pas d'héritage, pas de plein de chose qui font d'une api quelque chose de C++ friendly.

                      > > qui n'est parfois pas installee sur des systemes

                      >Il faudrait abondonner cet argument ridicule.
                      > yum/apt/urpmi/etc existe.
                      > Si je regarde kdebase (qui comme son nom l'indique est la base) j'ai les dépendances "bizarres" suivantes :
                      > audiofile-0.2.6-1 <= pour esound
                      > esound-0.2.35-1
                      > glib2-2.4.6-1 <= glib est déjà utilisé
                      > ...


                      Je ne pense pas qu'il remette en cause la facilité de déploiement.
                      C'est pour évité d'avoir des doublons de code et encore plus de dépendance nécéssaire. J'ai perso un système kde sans avoir la glib, la dépendance vient d'une dépendance a d'une autre lib, je pense qu'elle doit venir d'esound, comme je ne l'utilise pas je ne vois pas pourquoi je devrai saturé encore un peu plus mon sys avec des libs qui ne me sont pas nécéssaires.
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                        Posté par . Évalué à 1.

                        > pas d'itérateur, pas d'héritage, pas de plein de chose qui font d'une api quelque chose de C++ friendly.

                        J'amais content.
                        Ben faites votre Kstreamer dans votre coin qui sera "nobody friendly" et arrêter de critiquer le boulot des autres car il n'est pas "KDE friendly" alors que vous avez une attitude hostile à tout.

                        > je pense qu'elle doit venir d'esound

                        esound n'utilise pas glib (que la libc et alsa).
                        C'est arts (KDE) qui utilise glib.
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à 2.

                          On ne critique pas le boulot des autres, on crutique ton "C++ friendly" a propos de la glib
                          Je n'ai jamais dis que je ne voulais pas de gstreamer, je reportai les choix des devs kde, et je ne vois pas en quoi tu peux dire qu'on est hostile a tout.
                          Et on ne critique pas le travail des autres, par contre tu sembles avoir du mal a comprendre qu'on puisse ne pas être daccord avec toi.
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à 1.

                            > tu sembles avoir du mal a comprendre qu'on puisse ne pas être daccord avec toi.

                            Faut être conhérent avec moi sinon je suis dure de l'oreille. Jusqu'à maintenant et après beaucoup de requêtes, j'ai _AUCUN_ exemple de plus "C++ friendly" que par exemple gstreamer avec glib.
                            Le seul argument, et il est récurrent, est :
                            - le C++ est plus "C++ friendly"

                            Tu m'étonnes... que je suis d'accord. Mais ce n'est en rien convaincant.

                            De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.

                            Le seul argument qui mérite un peu d'être vérifié est par rapport à openssl que je ne connait pas. Mais openssl n'a rien pour aider de façon générique les bindings en language objet.

                            > on crutique ton "C++ friendly" a propos de la glib

                            Ben critiquez mieux.
                            btw, ça revient à critiquer glib et dire que glib n'est pas "C++ friendly" et non seulement à critiquer mon "C++....
                            glib n'a peut-être pas été faite pour être spécifiquement "C++ friendly" mais elle a été fait pour être objet friendly. Les bindings en languages objets de gtk+ le prouve.

                            Le C++ à part être "C++ friendly" est assez limité dans ce domaine.
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                              Bon, tout d'abord, il faut preciser que rien n'est C++ friendly. Le C++ est un langage complexe, surtout quand on le taquine un peu.

                              > De plus on dirait que vous faite exprès d'ignorer que Gnome à besoin d'utiliser le Language C pour faire des bindings.

                              Ah ouai ? Je me demande comment fait KDE pour faire des bindings. Ca doit etre impossible puisqu'il y a besoin du langage C. Va dire ca au mecs qui font PyQt, java for Qt, Qt#, rubyQt, perlQt, il seront content de savoir qu'ils ont besoin de faire du C.

                              Tu peux interpreter ca comme le fait que je fais expres d'ignorer cet argument parce qu'il me parait plus bancal qu'autre chose.

                              Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.

                              > Le C++ à part être "C++ friendly" est assez limité dans ce domaine [des bindings]

                              La on rentre dans un debat d'expert. Si tu discutes avec des gens qui font les bindings dans KDE et dans Gnome, tu pourras te faire ta propre opinion. La mienne (suite a ce genre de discussion), c'est que l'apparente facilite de generer des bindings en C cache une grande complexite, notamment au niveau de la maintenance. La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 2.

                                raté, Qt-csharp passe par qtc, qui est un binding en ... C ;)
                                "The bindings depend upon the QtC bindings by Richard Dale" sur la page principale de http://qtcsharp.sf.net(...)

                                Just my 2¢ qui n'invalide pas ce que tu dis par ailleurs.
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 4.

                                > Pour info, l'approche de KDE comme de Gnome sur les bindings c'est aujourd'hui d'avoir une espece de framework dynamique qui genere automatiquement les bindings. Seul le framework central est a maintenir.

                                Pas vraiment, pour gtk+ les bindings sont parfois générés automatiquement, parfois écrits à la main.

                                Accessoirement, le framework objet gobject a été pensé avec les bindings vers d'autres langages en tête, par ex lors de la destruction d'un objet, il y a deux "callbacks" différents qui sont appelés, ce mécanisme est essentiellement là parce que c'est utile à certains langages utilisant des garbage collectors.

                                > La syntaxe plus complexe et plus expressive du C++ permet une meilleure approche automatisee, tant au niveau de la generation que de la maintenance.

                                Ce qui est bien, c'est qu'encore une fois on peut utiliser cet argument pour expliquer que le C++ c'est nul comme langage, et que le C# serait plus adapté (je pense essentiellement aux possibilités d'introspection du C#)
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 1.

                                > PyQt, java for Qt, Qt#, rubyQt, perlQt

                                Bindings tellement géniaux qu'ils sont très peu utilisé.
                                J'avais regardé les bindings Qt il y a quelque temps et seul perlQt semblait utilisable.

                                Je ne comprends pas qu'on puis discuter ça. gtk+/Gnome a été fait avec les bindings en tête et Qt non.
                                Compte le nombre de programme qui utiliser des bindings gtk+ et ceux qui utilisent des bindings qt, et il y a au minimum un rapport de 10.
                                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                  Posté par . Évalué à 3.

                                  Bon je n'étais pas intervenu jusqu'à présent, mais je trouve tes propos très dédaigneux du travail des autres, vraiment...
                                  Et en plus tu as deux fois tord:
                                  -Quand bien même il ne serait pas utilisé, un projet peut être excellent,NetBSD ça te rappelle quelque chose?...et l'inverse est vrai aussi, un projet très utilisé peut être une grosse merde,Window$ ça te rappelle quelque chose?
                                  -Les bindings Qt sont utilisables et utilisés, y'a même un IDE de développement Python (BlackAdder je crois), qui est VENDU, et qui se vend bien !!
                                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                    Posté par . Évalué à -1.

                                    > je trouve tes propos très dédaigneux du travail des autres

                                    Quand glib/gtk+ etc se font chier pour être "C++ friendly" et que d'autres répondent que c'est "loin être C++ firendly", ça ne te dérange pas ?

                                    Tu trouves ça respectueux ?
                                    Si tu fouilles le thread tu trouveras quelqu'un qui dit que les bindings sont sans intérêts.
                                    Tu en penses quoi pour pyQt par exemple ?

                                    > NetBSD ça te rappelle quelque chose?

                                    Non.

                                    > Window$ ça te rappelle quelque chose?

                                    Oui et Windows n'est pas une merde.

                                    > Les bindings Qt sont utilisables et utilisés, y'a même un IDE de développement Python (BlackAdder je crois), qui est VENDU, et qui se vend bien !!

                                    Ben je me suis trompé. Je ne peux pas tout savoir.
                                    J'ai dit :
                                    - "J'avais regardé les bindings Qt il y a quelque temps et seul perlQt semblait utilisable"

                                    L'emploi du passé est assez "massif". Non ?
                                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                                  J'utilise PyQt tous les jours dans des applis professionelles.

                                  Qt# s'est casse la gueule vu que c'etait justement une horreur a generer mais en train de repartir.

                                  Il faut lire les blogs KDE pour voir l'apparente facilite de KDE + Qt avec le binding javascript.

                                  rubyQt a la faveur de Richard Dale, donc je pense qu'on va le voir avancer pas mal.

                                  perlQt a ete ecrit uniquement par David Faure, pour tenter de convaincre les developpeurs des outils mandrake de passer de perlGtk a perlQt. Honnetement, je pense que faire du perl avec du Qt, c'est un peu comme se mettre la tete dans un vide-ordure.

                                  > Je ne comprends pas qu'on puis discuter ça. gtk+/Gnome a été fait avec les bindings en tête et Qt non.

                                  Ca, c'est indeniable. Maintenant, dans les faits et sur le long terme, je pense que l'approche Gnome ne sera pas la meilleure.

                                  Cela dit, les bindings semblent en effet beaucoup moins utilises que sous Gnome. Du cote KDE, on explique ca par le fait que Qt etant beaucoup plus facile a utiliser que Gtk, les gens ont beaucoup moins ressenti la necessite d'acceder a la lib dans d'autres langages plus facile a manipuler.

                                  Il y a aussi le fait que a premiere vue, les bindings sont plus faciles a generer pour Gtk / Gnome.

                                  Et quand la communaute Gnome se dit qu'il faudrait trouver un langage plus facile pour developper avec Gnome et reflechit a C#, on se marre vu que developper avec KDE est facile (une fois que tu as passe la douloureuse etape de generation des makefile)
                                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                    Posté par . Évalué à 0.

                                    > Et quand la communaute Gnome se dit qu'il faudrait trouver un langage plus facile pour developper avec Gnome et reflechit a C#

                                    C'est pour développer des applis ! C'est le framework pour l'utilisateur final !
                                    Ce n'est pas pour le coeur de Gnome. libgnome, orbit, gconf, etc sera toujours en C.
                                    Gnome a déjà python/perl/ruby/etc pour développer facilement des applis.
                                    Et si tu veux développer en C++, tu peux.

                                    > on se marre vu que developper avec KDE est facile

                                    Mais ça reste plus lourd que d'utiliser python par exemple et ça ne peut pas remplacer les languages de scripts.

                                    > perlQt a ete ecrit uniquement par David Faure, pour tenter de convaincre les developpeurs des outils mandrake de passer de perlGtk a perlQt. Honnetement, je pense que faire du perl avec du Qt, c'est un peu comme se mettre la tete dans un vide-ordure.

                                    Ce qui montre bien la difficulté de faire des bindings avec Qt et que le choix du C et gobject n'est pas stupide.
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                      "Puis je le répète encore. KDE utilise déjà la glib."

                      FAUX

                      Arts utilise la glib(depuis peu)!!! Pas Kde. Tu as certains soft Kde qui sont linkés à des libs utilisant la glib comme kword afin de permettre a ce derniere de comprendre les formats gnome, mais ce n'est en rien obligatoire.
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                        Posté par . Évalué à 1.

                        > Arts utilise la glib(depuis peu)!!! Pas Kde.

                        Mouaifff...
                        Combiens de programme/lib kde utilisent arts ?
                        Tu peux aussi dire que KDE n'utilise pas libX11 ni la librairie C alors.
                        kdelib utilise arts.
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                          "kdelib utilise arts."

                          Et?

                          Kde n'est en rien dépendant de Arts et donc en rien dépendant de la glib. Quand les devels de Kde on choisis arts comme framework multimedia(pour kde 2.0 donc y'a un moment), arts n'etait pas linké à la glib :p

                          Va sur le site de Arts, tu vera que ce n'est pas un projet Kde.
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à 1.

                            > Kde n'est en rien dépendant de Arts

                            Très bien.
                            KDE ne supporte pas le son.
                            KDE n'a jamais eu de serveur de son.
                            C'est un add-on que les distribution ajoutent.
                            J'ignorais.

                            J'ai toujours du mal à comprend pourquoi kdelib en dépend...
                            Et pourquoi lorsque je fait "./configure --help | grep arts" dans les sources de kdelib (sans patch) j'ai :
                               --without-arts      build without aRts default=no

                            Si actuellement je vois arts sur le site de KDE :
                            http://www.kde.org/areas/multimedia/(...)
                              KDE Multimedia

                              Welcome to the KDE Multimedia site!
                              (...)
                              In KDE 2 and 3 these interfaces are largely built on the daemon and libraries of the Analog Real-Time Synthesizer, known as aRts.
                              (...)
                              These pages provide information on KDE multimedia and aRts.

                            C'est parque mon pétard n'était pas frais.

                            Maintenant tu peux faire comme Alex et dire que je suis bouché, et que je ne veux pas comprendre etc.

                            Non, ça je ne veux pas comprendre.

                            > Va sur le site de Arts, tu vera que ce n'est pas un projet Kde.

                            Vas sur le site de gtreamer, tu verras que ce n'est pas un projet Gnome.

                            Donc Gnome n'a aucune dépendance avec Gstreamer ?
                            Ben si, Gnome dépend de Gstreamer.
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                              Posté par . Évalué à 1.

                              Tu fais un "configure --help" dans les sources de kdelibs, tu as, entres autres :

                              --without-arts build without aRts default=no

                              Au plus, tu auras trois-quatre applis multimédia qui risquent de ne pas fonctionner après (dans kdemultimedia) car effectivement, elles s'appuient dessus.
                              Mais ce n'est en rien absolument nécessaire au coeur du système. J'imagine d'ailleurs que c'est la même chose pour Gnome vis-à-vis de Gstreamer.

                              Richard
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à 3.

                          Tu peux compiler tout KDE sans support Arts.
                          Et ouais.
                          Personnellement, je me fiche complètement des histoires glib/KDE/gnome etc. Je trouve que tu montes facilement sur tes grands chevaux, allant jusqu'à l'insulte, pour une histoire qui ne concerne au fond que les devs KDE. Je ne vois pas comment tu peux te permettre de leur reprocher quoi que ce soit en ce qui concerne les choix qu'ils font pour leur infrastructure et j'ose imaginer que, quand on décide passer des semaines en bénévole à coder un logiciel, on préfère le faire avec des outils qui paraissent simples à implémenter pour la langage qu'on utilise. Que ça te plaise ou non.

                          Richard
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à -3.

                            OK, c'est bon.
                            - glib est un problème de performance pour utiliser Gstreamer dans KDE
                            - les bindings ça ne sert à rien
                            - KDE et ARTS n'ont rien à voir ou presque
                            - glib est une horreur pour faire des binding en C++
                            - Qt ne dépent pas X11 (aujourd'hui)
                            - J'emmerde toutes les développeurs KDE qui sont tous des crétins (fallait bien que je les insulte quelque part).
                            - etc...

                            La vérité est rétablie. Dommez tranquille.
                            • [^] # pfffoooooouu

                              Posté par . Évalué à 5.

                              T'es vraiment pénible.
                              • [^] # Re: pfffoooooouu

                                Posté par . Évalué à -1.

                                Ben, faut dire aussi que vous êtes plusieurs à vous acharner sur lui dans ce thread.
                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                    Posté par . Évalué à 1.

                    Bon, on va passer sur la confusion glib/gobject, vu que les deux viennent dans la même tarball même si au final on a deux libs distinctes. La glib, c'est un ensemble de fonctions indispensables pour écrire un prog en C sans trop se prendre la tête (gestion de listes, de hash table, de chaines de caractères, ...), la couche C objet est totalement implémentée dans gobject, et la glib n'utilise pas du tout gobject.

                    > Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?

                    le C++ gère les signaux et les "properties" ? Non ? Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?

                    > quel est l'interet pour KDE de demander en plus de ses dependances classiques, une lib en C, qui n'est parfois pas installee sur des systemes, et qui fait la meme chose que Qt ?

                    Ca doit être chaud à trouver un système sans glib de nos jours ;) Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions ». Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...

                    > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder

                    Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...

                    > Il y a une reponse, mais comprend que si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi, indendamment des possilibites d'utiliser Qt en C (en imaginant qu'elles existent) ou des qualites intrinseques de Qt.

                    Si tu parles de gobject, je comprends ton point de vue, si tu parles de la glib (en excluant la partie C objet donc), faudrait arrêter de fumer la moquette :) C'est criminel aujourd'hui de forcer qqu'un à écrire un truc en C sans utiliser une implémentation de list, de hash table, ... toute faite. Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser, ou bien dbus pour des exemples de mecs qui se font vraiment chier à faire du C sans glib ou assimilé pour faire plaisir à qques extrémistes kdeiens...
                    Sinon QT n'est comparable ni à la glib, ni aux gobjects jusqu'au jour où QT sera splitté en plusieurs libs...
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                      Posté par . Évalué à 1.

                      > > Si c'est pour faire de l'objet, pourquoi ne pas faire du C++ ?
                      > le C++ gère les signaux et les "properties" ? Non ?

                      Je n'ai pas envis de rentrer dans le technique, mais ce qui m'énerve le plus dans "pourquoi ne pas faire du C++", c'est ce côté "la programmation object c'est pour C++ et pas pour les autres".

                      Le premier bouquin sur le C ("Le langage C" par Kernighan et Ritchie) indiquait qu'un bon programme était souvent orienté objet.
                      Suffit de regarder les sources de Linux pour détecter rapidement des parties orientées objets. Évidemment, ce n'est pas aussi luxueux que le C++ et on peut chipoter sur mon emploi de "orienté objet".

                      btw, faire de l'orienté objet avec du C est très vieux (libXt est un très bon exemple).

                      À la question "pouquoi faire de l'objet avec du C", je réponds :
                      - "Car la programmation objet c'est bien et le language C c'est bien."

                      > > si on propposait a Gnome une dependance vers Qt, ils feraient la gueule aussi

                      Qt est GPL. L'objectif de Gnome est d'avoir des librairies LGPL.
                      Qt ne permet pas les bindings (ou ce n'est pas terrible à de très rare exception).
                      Qt est payant sous Windows.
                      Qt est C++, il faut donc compiler l'appli avec un compilateur C++ (Il y a des techniques pour éviter ce problème mais c'est particuliairement ugly).
                      Qt dépend de X11 (et de plein d'autre trucs) alors que glib ne dépend que de la libc. Idéal aussi pour un programme non graphique. Donc rien à voir.

                      > C'est criminel aujourd'hui de forcer qqu'un à écrire un truc en C sans utiliser une implémentation de list, de hash table, ... toute faite.

                      Absolument. Surtout que l'empreinte mémoire de glib (hors gobject) est ridicule. Et en fait n'est chargé en mémoire que ce qui est utilisé.
                      De plus la multiplication des implémentations de list, hash table ... fait que ça bouffe plus de mémoire que si tout le monde utilisait la glib.

                      Du gâchis en place mémoire et en temps de développement et pour faire plaisir à "qques extrémistes kdeiens..." comme tu le dis.

                      PS : glib est un lib vraiment bien foutu. Un must pour développeurs C et quelque soit le type d'appli (graphique ou non).
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                        "Qt dépend de X11"

                        Bam, faux avec Kde 4.0 qui utilisera QT 4.0 !!
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à -1.

                          Tu calmes ta joie.
                          Qt dépend de X11.
                          Ça sera faux mais pour l'instant c'est vrai.

                          Bonne nouvelle, il est jamais trop tard pour bien faire...
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                            "Tu calmes ta joie.
                            Qt dépend de X11.
                            Ça sera faux mais pour l'instant c'est vrai."

                            Ben c'est pas de ma faute si depuis le debut du thread t'as pas compris qu'on parle de Kde 4.0... On s'en bat un peu les couilles de kde 3.4 et qt 3.4 :p Si un jour gstreamer est dans Kde, ca sera avec Qt 4!
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                              Posté par . Évalué à 3.

                              D'accord. C'est comme ça que KDE a toujours une version d'avance sur les autres...
                              Ils sont présentement à la version suivante.
                              Pour vous le présent, c'est la version futur.

                              Je sais, je répète. J'ai (ou j'avais ?) un peu de mal avec le concept.
                              Rassures toi, ça ira (ou ça va ? le présent c'est le futur..), heu non..
                              Rassures toi ça va mieux demain. Heu non plus.
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                        En fait il faut voirla glib comme ce que la libc aurait dû être; dès lors tout programme utilisant la libc devrait (ou en tout cas pourrait) utliser la glibc pour une fonctionnalité de base manquante à la libc (un truc assez chiant par exemple est l'abscence totale de toute fonction de manipulation de texte dans la libc).

                        Un programme peut legitimement refuser de dependre de la glib s'il ne depends pas de la libc, mais s'il a déjà une dependence vers la libc, alors il est tout à fait normal et logique d'aussi utiliser la glib.
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à 1.

                          > l'abscence totale de toute fonction de manipulation de texte dans la libc
                          ?
                          Par exemple :
                          man string.h

                          C'est dans la norme de la librairie C.
                          C'est rudimentaire, mais c'est normal.
                          Faire aussi :
                          info --node="String and Array Utilities" -f /usr/share/info/libc.info.gz

                          > Un programme peut legitimement refuser de dependre de la glib s'il ne depends pas de la libc

                          Les programmes qui ne dépendent pas de la libc doivent se compter dans sur les doigts d'une main. A ma connaissance :
                          - linux
                          - memtest86 ?
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à 2.

                            > C'est rudimentaire, mais c'est normal.

                            s/rudimentaire/mal foutu ? ;)
                            Y a pas mal de fonctions "dangereuses" (ie qui se favorisent les buffer overflow si tu fais pas gaffe aux cas particuliers), sans parler des pbs de portabilité. La glib résoud ces 2 problèmes. Donc c'est faux de dire que la libc n'a pas de fonctions de manipulations de chaine, mais je suis quand meme bien content d'avoir les fonctions fournies par la glib
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                              Posté par . Évalué à 1.

                              > s/rudimentaire/mal foutu ? ;)

                              Pas d'accord. Ce n'est pas le rôle de la lib C ou de POSIX (pour la lib C :-)) d'avoir des fonctions de haut niveau.
                              La lib C offre le minimum pour tout faire. Ça fait bizarre comme phrase mais c'est le cas. D'ailleur il n'y a pas le choix, tout fini par passer par la libc avant de passer par le noyau.

                              Le but est la vitesse, la taille, la vitesse, la taille et la portabilité.

                              Pour les fonctions "dangereuses", c'est principalement pour des raisons historiques. Puis la libc GNU a la délicatesse de mettre un warning lorsqu'on utilise une fonction dangereuse et de vérifier les appels des fonctions à nombres de paramètres variables.

                              > sans parler des pbs de portabilité.

                              J'ai développé des programmes qui doivent tourner sur plusieurs Unix et c'est assez mineur (entre système Unix !). Il y a des difficultés beaucoup plus dure ailleur (make, le shell, l'édition de lien des librairies partager, etc).

                              Puis ces problèmes de portabilité sont les problèmes classiques de non respect de norme. D'ailleur tu peux aussi installer la lib C gnu si la lib C de l'OS (proprio forcément) t'emmerde.
                              Par contre, et on s'y attend, c'est beaucoup plus merdique avec Windows.

                              > je suis quand meme bien content d'avoir les fonctions fournies par la glib.

                              Moi aussi, et bien que je trouve la lib C bien foutu (compte tenu des objectifs/contraintes) je pousse tout le monde à utiliser Glib qui est beaucoup plus "confortable", sûre et portable.

                              PS :
                              J'invite à lire la doc de la libc (info libc) qui est l'un des meilleurs moyens pour faire connaissance avec Linux.
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 2.

                                Mon "mal foutu" faisait surtout référence aux fonctions du genre strndup qui se comportent bizarrement dans les cas pathologiques. Et gcc ne te prévient pas dans ces cas là
                                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                  Posté par . Évalué à 1.

                                  > Et gcc ne te prévient pas dans ces cas là

                                  Ouais.

                                  > genre strndup

                                  C'est tout le "charme" de la lib C. Pour des raisons de vitesse, il n'y a aucun contrôle. C'est à ton programme de contrôler ou voir qu'un contrôle n'est pas nécessaire et gagner en vitesse (ce type d'optimisation est à faire au compte-goute, c-à-d après un profile).
                                  Par contre il y a des fonctions (ou des fonctions avec certains paramètres) qu'il faut éviter car là ton programme ne peut garantir que la fonction retournera...
                                  Typiquement il y a gets() et (f)scanf().
                                  Des solutions en restant avec la lib C existent mais c'est lourdingue (utiliser read() puis sscanf(), etc). Des extensions GNU fournissent des solutions fiables.

                                  Bref, on sent rapidement tout l'intérêt d'avoir la glib sous le coude :-)
                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                      Ah, je realise qu'il y en effet une grosse confusion de ma part entre glib et gobject. C'est plutot gobject que je critique dans l'absolu.

                      > Pourquoi est-ce que KDE rajoute ça (ça étant au moins les signaux) par
                      > dessus un langage qui ne le supporte pas, autant faire du C# plutôt que de réinventer la roue ?

                      C'est trolltech qui rajoute ca. En effet, ca peux sembler un bon argument. Cependant, au moment ou Trolltech a choisi d'ajouter des signaux, des slots et de proprietes aux objets C++, il n'y avait aucun equivalent sur le marche, a part vaguement java, mais qui conservait des performances catastrophiques.

                      Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.

                      > Disons que KDE a besoin d'un framework multimédia, il n'en existe pas utilisant QT nativement, donc arrêtez de faire les difficiles aussi « ah oui, on veut bien de votre framework multimédia, mais bon, on pose nos conditions »

                      C'est en etant tres selectif dans les technologies qu'il utilise qu'un projet etablit les bases technologiques de son succes. Ca vaut pour KDE (DCOP aui lieu de orbit), pour Gnome (orbit au lieu de mico), pour mozilla (un framework complet javascript ecrit pendant 3 ans avant de faire quoi que ce soit) et pour les autres.

                      On peut ne pas etre d'accord avec les choix faits, mais tu ne peux pas reprocher a un projet de choisir ses technologies soigneusement. Surtout quand il s'est deja plante une fois par le passe.

                      > Le pire, c'est que si le framework en question réécrivait à partir de 0 ce qui est contenu dans la glib, il y aurait moins d'opposition...

                      Ca ne ressort pas dans mes posts, mais personellement, je suis pour l'utilisation de la glib pour tout projet en C. Parce que si tu ne l'utilises pas, tu vas finir par la recoder tout de meme.

                      > > Pour info, le framework objet du C++ est plus rapide, plus efficace et plus simple a coder
                      > Plus rapide et plus efficace ? En tout cas pour les trucs de base (héritage, ...) je vois pas trop en quoi ça serait plus rapide à l'exécution...

                      Je pensais a gobject. Pour la glib, je ne pense pas qu'il y aie de difference. D'ailleurs, quand on regarde sous les QList, on voit des grosses optimisations typiques du C (et vas-y que je te malloc tout ca et que je me deplace avec des additions sur les pointeurs).

                      > Cf le code de xdgmime qui a été écrit sans utiliser la glib entre autre en espérant que les gars de kde accepteraient de le réutiliser

                      Un naif qui s'est fait avoir. Honnetement, je pense que le consensus dans KDE est d'avoir du code propre. Apres, ca donnes des interpretations differentes sur les moyens d'arriver a ce but. Ce qui est sur, c'est qu'un mec qui recode glib a la main sera encore moins bien vu (en tout cas pour moi) puisqu'il choisit de code vite fait un truc qui existe deja et est plus stable.

                      Pour ce qui concerne dbus, il me semble qu'il utilise glib mais qu'il embarque les sources directement. Comme ca, pas de problemes de dependance. Il me semble que c'est aussi ce qui avait ete envisage avec arts.
                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                        Posté par . Évalué à 3.

                        > Ca fait une grosse difference avec Gnome qui a choisi entre plusieurs langages objets: C, C++, objective C, et qui a finalement opte pour le moins objet de tous.

                        A l'époque, une des raisons du choix du C devait être le fait que c'était le seul langage pour lequel il existait des compilateurs fonctionnant parfaitement (ou presque) sur toutes les plateformes, à l'époque, pour faire du C++ portable, fallait en gros se limiter aux fonctionnalités "simples" du langage. Ensuite, quand tu prends en compte que le c++ ne fournit pas toutes les fonctionnalités voulues, et qu'il y a un certain nombre de subtilités un peu chiantes à saisir, le choix du C peut se comprendre.

                        > Je pensais a gobject

                        Même dans le cas des gobjects, je ne pense pas qu'il y ait de vraies différences de perf, à part peut être à la création des objets, mais j'ai le sentiment que cette création est plus flexible qu'en C++ (mais je ne connais pas trop le C++...)

                        > Un naif qui s'est fait avoir.

                        Où plutôt un employé de RedHat à qui Havoc et Owen ont demandé de faire du code "nu" pour faciliter l'adoption

                        > Comme ca, pas de problemes de dependance.

                        Et de gros problèmes de maintenances en cas de grosse faille de sécu à boucher rapidement... (enfin la glib n'est probablement pas une lib critique de ce point de vue là)
                        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                          Posté par . Évalué à 1.

                          Non le choix du C ne peut pas se comprendre...en 1987 NeXT choisit Objective-C pour faire un framework de développement propre et objet, solide bien conçu et réutilisable....DIX ans après Gnome n'est pas capable de faire le bon choix LOL (enfin sauf si un choix qui a plus de dix ans de retard est bon !!!)
                          Le C pour concevoir un framework orienté interface graphique c'est comment dire...débile?absurde?con?
                          • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                            Posté par . Évalué à 0.

                            > c'est comment dire...débile?absurde?con?

                            C'est pas toi qui me parle de respect un peu plus haut ?
                            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                              Posté par . Évalué à 0.

                              Tu sais que t'es assez irritant comme garçon...oui le choix est débile, ce qui n'est pas une critique envers le travaille des devs style "leur projet tout le monde s'en fout personne l'utilise c'est de la merde".Le projet est au contraire très intéressant, apporte beaucoup de chose, y'a eu beaucoup de bon boulot de fait, mais le choix du C est foireux quand même.
                              D'ailleurs tous les matins tu cours le 100 mètres le plus vite possible...mais à cloche-pied, et bien sûr tu trouves insuportable qu'une personne te fasse remarquer que tu serais plus performant en courant avec tes deux jambes...c'est la logique 007 !!
                              • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                Posté par . Évalué à 0.

                                Un bon projet, qui fait du bon boulot avec de bon résultat et tout ça avec un choix foireu, débile, con...

                                Intéressant comme concept.

                                > c'est la logique 007 !!

                                Non. Ta logique (mais il faut vraiment cherche la logique) est :
                                - Faire le choix foireux, débile, con de courrir le 100 mètres à cloche-pied n'empêche pas d'être rapide.

                                Perso, j'ai beaucoup de mal avec cette logique.

                                Ma "logique" est presque à l'opposé. Si le résultat est bon alors le choix ne peut pas être foireux.
                                Si je suis champion du monde (ou médaillon d'argent après Qt :-)) au 100 m, comment oses-tu dire que mon choix de courir le 100 mètres à cloche-pied est foireux, débile, con, etc ?

                                Tu peux m'explique ?

                                Tu vas me dire que je serais plus rapide avec les deux jambes. C'est peut-être vrai, mais tu réécris l'histoire et quoi qu'il en soit ça ne te permet pas de dire que la choix était foireux.
                                • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                                  Le C n'est PAS un langage orienté objet. Point.

                                  Pourquoi s'embêter à refaire un framework pseudo-objet pour développer en objet alors qu'utiliser un langage orienté objet (pas forcément C++) est beaucoup plus logique ?

                                  D'après les posts précédants, gobjects ne propose pas d'héritage. Comment peut-on appeler ça un framework objet s'il n'y a pas d'héritage ? C'est l'un des concepts de base (avec le polymorphisme et la redéfinition de méthodes) du développement objet !

                                  Je ne dénigre pas gobjects qui a certainement de grandes qualités, mais cette bibliothèque ne permet PAS de faire du développement objet.
                                  • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                    Posté par . Évalué à 1.

                                    > Le C n'est PAS un langage orienté objet. Point.

                                    Ce qui ne fait en rien avancer le débat.
                                    Il y a des compilateurs C++ qui convertissent le C++ en code C puis le passent à un compilateur C "normal".
                                    "Pire", au final c'est toujours de l'assembleur qui est compilé...

                                    > D'après les posts précédants, gobjects ne propose pas d'héritage.

                                    D'après un post sur linuxfr...
                                    Ça ne remplacera jamais la doc.

                                    > mais cette bibliothèque ne permet PAS de faire du développement objet.

                                    Dis moi, ton analyse est basée sur les commentaires de dlfp uniquement ?
                                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                      Posté par . Évalué à 3.

                                      > Ça ne remplacera jamais la doc.

                                      Quel vilain je suis, j'ai oublié de mettre la doc :
                                      http://www.gtk.org/documentation.html(...)
                                      Gobject (introduction) :
                                      http://le-hacker.org/papers/gobject/index.html(...)
                                      Pour l'héritage, c'est ici :
                                      http://le-hacker.org/papers/gobject/ch02s04.html(...)

                                      Pour les trolls, c'est toujours la même addresse :
                                      http://linuxfr.org/(...)
                                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                                      Puisque personne n'avait rectifié, j'ai effectivement supposé que c'était vrai.

                                      J'ai regardé les documentations, et ma première impression est que le C n'est définitivement pas orienté objet. Ce n'était pas son but et il reste un excellent langage que j'utilise dans certains cas.
                                      Mais utiliser une bibliothèque pour pallier à des manques conceptuels d'un langage rend le code plus touffu et moins compréhensible par manque d'une syntaxe adaptée. Tout simplement parce que dans un cas tu utilises un bibliothèque alors que dans l'autre, c'est le compilateur qui fait le boulot. Je trouve le code des exemples (donc normalement simples) illisible par rapport aux langages objet comme Python, Java, Objective C ou C++. Ce qui ne facilite pas la maintenance.

                                      Certes tout se réduit à du code hexa, mais pourquoi a-t-on inventé des langages de haut niveau ? Pour se faciliter la vie. Et là, au lieu d'utiliser un langage adapté, on prend un langage auquel on ajoute des bibliothèques. S'il n'y avait pas eu d'alternatives possibles, pourquoi pas. Mais ce n'était pas le cas.
                                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                        Posté par . Évalué à 3.

                                        > le C n'est définitivement pas orienté objet.

                                        Bien, bravo.

                                        > Mais utiliser une bibliothèque pour pallier à des manques conceptuels d'un langage rend le code plus touffu et moins compréhensible par manque d'une syntaxe adaptée.

                                        T'as lu la doc ?
                                        Je ne crois pas.
                                        Gobject est pour faire des objets (pas seulement) qui sont visibles par tous les languages ! Si une lib est faite en utilisant Gobject, tu as un binding pour perl et python automatiquement (et pour C# c'est pratiquement terminé).

                                        C++ fait-il ça tout seul ?
                                        Non !


                                        Alors je répète pour la dernière fois :
                                        - Si tu ne veux pas de binding et que C++ est parfait pour ton projet, n'utilise pas gobject et utilise C++.

                                        C++ est définitivement mieu que le C pour la raison trivial que tous ce que fait le C, C++ peut le faire.
                                        Mais (car il y a un/plusieurs mais) ceci est vrai si ton intention est de faire du C ou du C++ UNIQUEMENT ! Or Gnome c'est pour faire de C/C++/perl/python/php/ruby/etc.
                                        Enfin (et ce n'est mais pas le dernier problème) l'édition de lien en C++ est différente qu'en C. En C, tu ne peut pas appeler du C++. Faut truc ugly non portable et c'est ce que doit faire Qt pour ces bindings.
                                    • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

                                      > Il y a des compilateurs C++ qui convertissent le C++ en code C puis le passent à un compilateur C "normal".

                                      Ouai, en 1979, c'est comme ca qu'on faisait un compilateur C++. Bienvenue dans le nouveau millenaire.

                                      La richesse syntaxique du C++ permet au compilateur de mieux comprendre l'intention du programmeur et d'y faire des optimisations specifiques.

                                      En faisant un framework objet en C, tu perds toutes ces optimisations faites par le compilateur et tu dois te palucher bien plus de code a la main.

                                      Sinon, je tiens a defendre ton point de vue : le choix de gnome de faire du C se defend, notamment du point de vue des bindings. L'autre argument, c'etait tout simplement la disponibilite de Gtk bien qu'en y repensant, wxWindows devait etre deja disponible.

                                      L'argument du C++ mal supporte n'est pas genial : d'une part, Qt s'en sortait donc il n'y a pas de raison que Gtk en s'en sort pas non plus. D'autre part, un projet comme Gnome vise sur le long terme et peut compter sur l'amelioration des compilateurs.

                                      Je pense personellement que ce n'etait pas un bon choix parce qu'une appli graphique est fondamentalement objet et qu'il semble des lors plus approprie de choisir un langage dont la caracteristique objet fait partie du coeur.

                                      Sinon, on peut faire de l'objet en assembleur.
                                      • [^] # Re: Re : Les nouveautés du prochain X11R6.8

                                        Posté par . Évalué à 1.

                                        > Sinon, je tiens a defendre ton point de vue : le choix de gnome de faire du C se defend, notamment du point de vue des bindings.

                                        Merci.

                                        Juste à titre d'"exemple", je devais faire un programme graphique qui utilisait une lib C++, lib qui n'avait pas pour objectif d'avoir des bindings.

                                        Ben j'ai utilisé C++/Qt. Normal. Le choix de Qt a été dicté car Mac OS et Windows aussi...
                                        Mais même pour uniquement Unix j'aurai pris Qt.
            • [^] # Re: Re : Les nouveautés du prochain X11R6.8

              Posté par . Évalué à 1.

              Je crois que arts s'appui sur des kio_slave pour utiliser le réseau... on reste loin de se que propose nmm, mas...
        • [^] # Re: Re : Les nouveautés du prochain X11R6.8

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

          "Je ne veux pas me battre avec toi (utilisateur kde?) :
          KDE a raison, les autres tords (dont moi) et ils ne font que troller."

          Bwarf. C'est marrant, j'utilise Kde donc je suis contre gstreamer, faut arreter ton délire mon pauvre.

          Je ne veux pas de MAS dans Kde si tu veux mon point de vu: trop de fonctionnalitées inutiles pour un desktop.

          Et je suis 100% pour gstreamer meme si il est vrai que NMM semble aussi intéressant.

          Mais si tu veux savoir, actuellement, gstreamer a été choisi meme si Markey(devel de amarok) veut un wrapper afin que Kde puisse utiliser les deux. Mais, tout le monde n'est pas d'accord avec lui. Puis de toute facon, si Kde supporte les deux, gstreamer prendra le dessus vu que la majorité des distrib supporte gnome et kde. Ils vont pas s'amuser a foutre deux framework multimedia dans la distrib alors qu'avec un c'est possible.
  • # x.org 6.8, kde 3.3 et screens

    Posté par . Évalué à 6.

  • # DMX

    Posté par . Évalué à 4.

    # DMX (Distributed Multihead X) : permet de combiner les affichages de plusieurs machines (contrairement à Xinerama, qui utilise les affichages d'une seule machine)

    Miam!
    Avoir l'ecran du laptop et l'écran du desktop a coté, avec une seule souris, un seul clavier. j'en veux..
    • [^] # Re: DMX

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

      C'est déjà possible sans toucher à X: ça s'appelle Synergy, ça tourne sous Windows et OS X aussi, il y a un package Debian et ça marche bien.

      http://synergy2.sourceforge.net/(...)

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: DMX

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

        Pour détail ça veut dire que tu peux avoir un mac un win et un linux a coté, avec une seule souris et un seul clavier pour tous :)
      • [^] # Re: DMX

        Posté par . Évalué à 4.

        C'est peut etre pas la même chose si on peut pas combiner les deux affichages en un seul écran logique.
      • [^] # Re: DMX

        Posté par . Évalué à 2.

        Je pense que DMX doit lui-être supérieur, car avec synergy il n'est pas possible par exemple de déplacer une fenêtre d'un coté a un autre, les copiés/coller sont assez limités... par contre synergy a l'avantage d'être multi-plateforme, a prioris DMX ne marche qu'avec des serveurs X (et surement que xorg)
    • [^] # Re: DMX

      Posté par . Évalué à 2.

    • [^] # Re: DMX

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

      Outre les précédents commentaires, tu peux aussi regarder sur http://allergy.alrj.org/gruik/(...) (surtout le dernier point : « En attendant »). Avec x2x et ssh, je peux partager souris et clavier entre mon desktop et mon laptop.

      Malheureusement, ça reste deux serveurs X indépendants, donc pas question de faire passer une fenêtre de l'un à l'autre.
  • # A propos de DMX

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

    Bonjour,

    DMX (Distributed Multihead X), n'ai pas une nouveaute du serveur X de freedesktop.
    Ce projet existe depuis pres de 3ans.
    Je l'ai utilise quelque temps : http://etudiant.epita.fr/~nowick_c/index.php?desktop.html(...)
    Il faut savoir que cela ne marche pas avec les drivers proprio de Nvidia (je n'ai pas tester avec les drivers ATI).
    Le serveur se lance et plante sans message d'erreur.
    Visiblement il manque des extensions avec les drivers proprio pour le faire marcher.
    La meilleur chose a faire si vous voulez tester le projet c'est d'avoir des drivers libre sur les n ecran.
    Il faut aussi savoir que le projet est extrement gouramand en resources reseau. Il faut une carte reseau giga bit pour jouer de la video (ca rame mechament sur du 100 Mbits sur mon screenshot).

    Voilou

Suivre le flux des commentaires

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