KDE 3.4 officiellement sorti

Posté par  . Modéré par Amaury.
0
17
mar.
2005
KDE
La nouvelle mouture de KDE est officiellement sortie aujourd'hui, après 6 mois de développement, deux betas et une release candidate. KDE 3.4 c'est 80.000 nouvelles contributions, 6.500 bugs corrigés et 1.700 demandes de fonctionnalités qui ont trouvé une réponse. C'est également un début d'intégration de HAL et DBUS, de nombreuses améliorations dans le support PDF, le support complet de CSS 2.1 et un début de support de CSS 3, une nouvelle corbeille, un nouveau tableau de bord, un meilleur support du SVG et bien plus.
L'accessibilité n'est pas non plus oubliée avec l'intégration de KTTS, permettant de faire du "text to speech" (lecture audio de texte).

Pour ceux qui ne le sauraient pas, KDE est un environnement de bureau libre pour Linux/BSD qui se veut complet, efficace et multi plate-formes.

NdM: Merci également à gnumdk pour cette dépêche. Des packages sont déjà disponibles pour Gentoo, Arch Linux, SuSE RedHat... sinon il vous reste toujours l'option konstruct.

KDE 3.4 ne sera finalement pas le dernière version de KDE 3.x, le temps pour les développeurs de kdelibs de porter la base sous Qt4, une version de KDE 3.5 devrait sortir.

Bref pas mal de nouveautés, l'équipe devrait a priori commencer à travailler sur KDE 4 et ces nombreuses nouveautés tel que klink (framework permettant de faire des liens entre données, présenté au FOSDEM), kdemm (un "frontend" pour différent framework multimédia), sûrement l'abandon des autotools pour un autre système... D'ici là, il reste de nombreuses questions, comme le choix d'un nouveau framework multimédia, l'intégration de DBUS...

Aller plus loin

  • # Autre chose prévue

    Posté par  . Évalué à 8.

    L'équipe de KDE prévoit aussi de passer à subversion afin de remplacer leur CVS.
    C'est intéressant dans le sens où ça sera la plus grosse migration jamais faite de CVS vers subversion !
    Maintenant, qu'est-ce-que ça va apporter ? Plus de fonctionnalités ? Plus de sécurité ? Plus de fonctionnalités pour les développeurs de KDE ?
    • [^] # Re: Autre chose prévue

      Posté par  . Évalué à 3.

      Surement moins de webcvs down déjà, ce qui arrive souvent avec kde
    • [^] # svn vs cvs

      Posté par  (site web personnel) . Évalué à 9.

      J'ai eu l'occasion d'avoir à utiliser les deux en tant que 'newbee', en commançant par subversion.

      Du point de vue de l'utilisateur, svn n'apporte pas grand chose par rapport à cvs, mais du point de vue du contributeur, le 'préposé au remplacement' est bien plus agréable, car les commandes sont plus apparentées à celles des shells Unix.

      Sinon, question stabilité et performance, je ne sais pas, le projet est de petite taille, et nous n'avons pas assez de recul pour donner un avis pertinent.
      • [^] # Re: svn vs cvs

        Posté par  . Évalué à 9.

        Subversion ne prétend pas être révolutionnaire par rapport à CVS mais il apporte une réponse à tout un ensemble de problématiques qui n'étaient pas ou alors très mal gérés par CVS, notamment le renommage de fichiers ou de répertoire, ou leur déplacement. Je pense que la gestion des verrous est bcp plus "propre" avec subversion que cvs.

        Subversion fonctionne aussi avec WebDAV, ce qui est très pratique pour gérer ses "repository".

        Mes 2 cents.
        • [^] # Re: svn vs cvs

          Posté par  . Évalué à 2.

          Trac est tres bien aussi
          http://www.edgewall.com/trac/(...)

          quoique aucune idée comment il se positionne par rapport a webdav
          • [^] # Re: svn vs cvs

            Posté par  . Évalué à 4.

            je quote la page du site ....

            What is Trac?
            An integrated system for managing software projects
            An enhanced wiki
            A flexible web-based issue tracker
            An interface to the Subversion revision control system


            bref, trac C'EST subversion .... (enfin, tout un environnement de dev au dessus de subversion pour etre précis)
      • [^] # Re: svn vs cvs

        Posté par  . Évalué à 10.

        > Du point de vue de l'utilisateur, svn n'apporte pas grand chose par rapport à cvs

        D'un point de vu utilisateur, subversion apporte beaucoup.
        - Tout est utf8
        - support des répertoires
        - meta-donné arbitraire
        - support de lien symboliques
        - copie à coût 0
        - meilleur suivi des changelog même dans le cas de branchement
        - renommage des fichiers/répertoires et déplacement des fichiers/répertoires les doigts dans le nez
        - atomicité des transactions
        - une transaction n'est pas une petite modif dans un coin, c'est tout changement d'arborescence. Par exemple une transaction peut être le passage de Linux 2.2.0 à Linux 2.6.11. Ça reste une seule modification et atomique.
        - spécification de l'outil diff à utiliser. Ainsi, les modifications de données binaires sont supportés (le dépôt empile les diffs et pas les objets binaires complet)
        - etc

        svn apporte beaucoup par rapport à cvs pour l'utilisateur final.

        > le projet est de petite taille

        le src.rpm de cvs : 2 362 ko
        le src.rpm de svn : 7 978 ko
        • [^] # Re: svn vs cvs

          Posté par  . Évalué à 9.

          >> le projet est de petite taille

          >le src.rpm de cvs : 2 362 ko
          >le src.rpm de svn : 7 978 ko

          Je pense que lorsqu'il écrivait "le projet est de petite taille", il pensait au projet qu'il menait, pas aux projets cvs/svn.
        • [^] # Re: svn vs cvs

          Posté par  (site web personnel) . Évalué à 6.

          La fonctionnalite qui me plait le plus avec subversion, c'est qu'on peut faire un diff de facon instantanee, sans avoir une connexion avec le serveur.

          Les astucieux auront tout de suite note que cela signifie que tous les fichiers sont en double en local: version modifiee et version non modifiee. Ca prend donc deux fois plus de place, mais les fichirers texte ne prennent pas beaucoup de place.

          A cote de ca, c'est _super_ pratique de pouvoir annuler ses changements rapidement, ou bien de regarder ce qu'on a change en une seconde.
          • [^] # Re: svn vs cvs

            Posté par  . Évalué à 3.

            > La fonctionnalite qui me plait le plus avec subversion, c'est qu'on peut
            > faire un diff de facon instantanee, sans avoir une connexion avec le
            > serveur.

            à ce propos, je me suis toujours demandé si avec CVS, les diffs étaient confidentiels...
            Il me semble que ça se fait sur le serveur, qui t'envoie le diff après coup non?
            désagréable idée...
    • [^] # Re: Autre chose prévue

      Posté par  (site web personnel) . Évalué à -4.

      Plus de trolls sur DLFP ?


      oupssss une porte --------------> []

      \_o<

      • [^] # Re: Autre chose prévue

        Posté par  . Évalué à -2.

        s/DLFP/tribune/

        En plus pour pouvoir troller il faut quand même se taper 3 heures de compilation et quelques heures de test, ou alors attendre l'intégration du nouveau kde dans experimental/unstable au risque de se taper un upgrade foireux avec des dépendances toutes cassées :-), et ceci n'est pas un troll poilu.

        bon ok j'arrive ---> []

        dabowl_75

        • [^] # Re: Autre chose prévue

          Posté par  . Évalué à 2.

          oups on me souffle à l'oreille que kde est déjà dans experimental et que ça marche bien, bon j'ai rien dit :-)

          dabowl_75

    • [^] # Re: Autre chose prévue

      Posté par  . Évalué à 4.

      alors là je suis content de ma découverte parce que je n'ai pas trouvé de lien publique et j'aime bien leur todo plutot bien fait :

      http://developer.kde.org/development-versions/kde-3.5-features.html(...)
      http://developer.kde.org/development-versions/kde-4.0-features.html(...)

      vivement les futures versions ! :D
    • [^] # Re: Autre chose prévue

      Posté par  (site web personnel) . Évalué à 3.

      Sauf erreur de ma part, il faut ajouter a la liste des améliorations déjà citées une charge et une consommation de bande passante nettement réduite sur le serveur.
  • # JuK

    Posté par  (site web personnel) . Évalué à 5.

    A noter au passage, juK supporte maintenant les pochettes des albums via google image et ca marche trop bien, mieux que celui d'amaroK. Seul probleme, juK ne supporte pour le moment pas le standard freedesktop.

    Le systray à lui aussi été amélioré en permettant de cacher certaines applications à la windows XP. Les devels de kde esperent bien pouvoir faire ca plus proprement avec D-Bus pour kde4.
    • [^] # Re: JuK

      Posté par  . Évalué à 3.

      >Le systray à lui aussi été amélioré en permettant de cacher certaines applications à la windows XP.

      Qu'est ce que c'est, ça? Et à quoi est-ce que ça sert, de cacher des applications?
      • [^] # Re: JuK

        Posté par  . Évalué à 5.

        C'est vrai que de prime abord ça ne sert pas à grand chose mais c'était un des voeux les plus demandés.

        J'y ai cependant trouvé une application : la solution la plus simple (quand on est sous kde) pour prendre en compte les touches volume du clavier est d'activer son clavier dans le centre de contrôle de kde. Cela rajoute deux icones dans le tray : le drapeau de la langue du clavier et l'icone de kmix, qui se lance dès qu'on appuie sur la touche. Je n'ai a priori pas besoin de voir ces deux icones, et elles prennent de la place, mais j'ai besoin des services qui y sont associés.

        On pourait se dire que ces programmes devraient inclure une option "ne pas afficher l'icone", mais cela va peut-être à l'encontre de la philosophie du bureau destiné à monsieur tout le monde en lui rappelant que ces programmes tournent en tâche de fond
        • [^] # Re: JuK

          Posté par  . Évalué à 4.

          Si tu te contente uniquement du clavier Français (donc en virant le clavier américain présent par défaut), il est parfaitement possible de ne pas avoir l'icône du petit drapeau dans le systray, il suffit de laisser l'option Afficher l'indicateur lorsqu'une seule disposition est sélectionnée décochée :-)

          Et sinon, en ce qui concerne kmix, pourquoi ne pas passer par aumix pour le réglage du son via le clavier ? Du coup, kmix n'aurait plus besoin d'être lancé, donc plus d'icône non plus :-p
        • [^] # Re: JuK

          Posté par  . Évalué à 2.

          C'est vrai que de prime abord ça ne sert pas à grand chose mais c'était un des voeux les plus demandés.

          Cela signifie aussi que la philosophie de la plupart des nouveaux utilisateurs est « Je me mettrai à Linux le jour où il ressemblera à Windows ».

          Pas très encourageant, à dire vrai ...
          • [^] # Re: JuK

            Posté par  (site web personnel) . Évalué à -1.

            Cela signifie aussi que la philosophie de la plupart des nouveaux utilisateurs est « Je me mettrai à Linux le jour où il ressemblera à Windows ».
            Pas très encourageant, à dire vrai ...


            Il ne faut pas se leurrer, c'est cette ressemblance qui a toujours attiré énormément de monde vers KDE.
            • [^] # Re: JuK

              Posté par  (site web personnel) . Évalué à 4.

              Et inversément, c'est une des raisons qui m'a fait me tenir éloigné de KDE.

              Jusqu'il y a environ deux ans, époque à laquelle j'ai redonné sa chance à cet environnement, qui m'a alors séduit.
              Évidemment, il avait évolué (et moi aussi probablement).

              Maintenant, je l'utilise parce qu'il me plaît, et je ne peux pas trop parler de ressemblances avec Windows puisque je n'ai plus réellement utilisé ce dernier depuis ses version 98 et NT4.
            • [^] # Re: JuK

              Posté par  . Évalué à 10.

              Je pense qu'il faut arrêter de dire "KDE ça ressemble trop à windows, donc je ne l'utilise pas".

              KDE comme dit sur le site officiel "fait son propre chemin".
              KDE ne ressemble à rien d'existant, ou il ressemble à tout ce qui existe (cochez ce qui vous convient, il n'y a pas de bonne/mauvaise réponse).

              L'interface KDE c'est celle windows, MacOS, ou d'autre encore (pas d'exemples, ma culture générale en terme de GUI est assez limitée, et je ne sens pas le besoin de l'appronfondir).

              KDE c'est KDE, point. S'il "pique" des idées par-ci par là sur des interfaces existantes et qui ont fait leur preuve, tant mieux.

              KDE est modulable à souhait, configurable à 150% et même plus...
              KDE, c'est bon.
              • [^] # Re: JuK

                Posté par  (site web personnel) . Évalué à 3.

                KDE comme dit sur le site officiel "fait son propre chemin".

                Je ne dis pas le contraire. Aux origines du projet, on le vendait comme une interface graphique «comme Windows» pour Linux/*BSD/etc.

                La personne à qui je répondais avait l'air de dire que cette volonté de retrouver une interface qui ressemble à Windows était propre aux «nouveaux utilisateurs» et qu'il ne trouvait pas ça «très encourageant». J'ai l'impression qu'il ne se rend pas bien compte de quand elle date, cette volonté.
        • [^] # Re: JuK

          Posté par  . Évalué à 2.


          On pourait se dire que ces programmes devraient inclure une option "ne pas afficher l'icone", mais cela va peut-être à l'encontre de la philosophie du bureau destiné à monsieur tout le monde en lui rappelant que ces programmes tournent en tâche de fond


          pour le drapeau, ca fait partie des options

          kmix aussi peut, mais ca le fait planter... (enfin, ca le faisait avec kde 3.3.x, je n'ai pas essayé avec 3.4)
          • [^] # Re: JuK

            Posté par  (site web personnel) . Évalué à 2.

            kmix aussi peut, mais ca le fait planter... (enfin, ca le faisait avec kde 3.3.x, je n'ai pas essayé avec 3.4)
            (Juste pour dire que chez-moi-ça-marche, KDE 3.3.2 et KMix 2.2rc1)
  • # Sous Debian...

    Posté par  . Évalué à 5.

    Des packages sont déjà disponibles pour Gentoo, Arch Linux, SuSE RedHat... sinon il vous reste toujours l'option konstruct.


    Et sous Debian il ne faut pas oublier les packages disponibles sur alioth :

    deb http://pkg-kde.alioth.debian.org/kde-3.4.0/(...) ./

    Je me suis laisse dire que ces paquets etaient maintenus par des devs de KDE donc bon, ca devrait etre relativement serieux (pas teste, pas taper).
    • [^] # Re: Sous Debian...

      Posté par  (site web personnel) . Évalué à 1.

      Uniquement pour i386, cependant.
      • [^] # Re: Sous Debian...

        Posté par  . Évalué à 2.

        Non, j'ai buildé des paquets pour powerpc (un tout petit peu moins à jour que les i386 néanmoins) mais le pb c'est que un firewall a été monté (je suis en relation avec le sysadmin pour qu'il me rouvre le port qu'il me faut) et que la repo est plus accessible pour le moment.


        btw, j'ai fait un post sur debian-qt-kde@lists.debian.org à ce sujet, ca doit se trouver facilement dans les archives.

        --
        Proud Debian KDE Packager
    • [^] # Re: Sous Debian...

      Posté par  . Évalué à 5.

      je remets ce que j'ai mis dans le journal :
      c'est l'équivalent d'experimental
      j'ai pas trop suivit pourquoi mais apparemment les mainteneurs kde ne veulent pas le mettre dans experimental mais ce dépot est à considérer comme tel (donc pas forcément parfait mais supporté et correct)
      y-a déjà eu des commentaires dessus et il semble fonctionner correctement (à part arts qui peut poser pb avec les .ogg)

      les i18n seront bientot sur alioth (ils sont sur people.debian.org pour le moment) mais ont déjà un pb de dépendance (au niveau des versions)

      et pour ceux qui auraient pas compris : ce sont les mainteneurs officiels qui s'en occupent


      petite remarque : les packages ont été entièrement refaits avec cdbs au lieu et place de debhelper (les mainteneurs font en sorte que le fichier de conf cdbs puissent fonctionner pour n'importe quel appli kde qui n'est pas encore packager pour faciliter l'ajout de nouveau programme kde dans debian)



      sinon je viens d'installer ces paquets et ils marchent très bien
      l'installation se passe sans soucis
      - il manque juste kdm (il faut installer la version 3.3.2-1b disponible sur alioth, la version 3.4 à encore besoin de travail apparemment)
      - je confirme le pb de dépendance avec kde-i18n :
      il suffit de forcer l'install du paquet. Pour ça perso j'ai téléchargé le paquet à la main et je l'ai installé avec la commande :
      dpkg --force-depends -i kde-i18n-fr*.deb
      puis éditer le fichier /var/lib/dpkg/status en changeant, dans la section depends, la version pour kdelibs4 en 4:3.4.0-0pre1 pour éviter que apt-get ne cherche à désinstaller kde-i18n-fr à chaque fois que vous cherchez à mettre à jour votre système (entre autre)
      • [^] # Re: Sous Debian...

        Posté par  . Évalué à 2.

        Je viens de l'installer en suivant ta méthode pour la localisation. Et ça marche très bien. Je n'ai pas de problème. Merci!

        Sinon, pourquoi il y a un problème avec les dépendances pour le paquet de la localisation?
        • [^] # Re: Sous Debian...

          Posté par  . Évalué à 1.

          une erreur d'inattention du mainteneur
          il a dit qu'il règlerait ça bientot, mais vu que la bande passante n'est pas illimité, je peuse qu'il va falloir faire avec pendant quelques temps
          • [^] # Re: Sous Debian...

            Posté par  . Évalué à 1.

            Je viens (peut-être) de trouver un bug.

            Lorsque je veux mettre un fichier dans la corbeille il me dit que le kioslave trash n'existe pas. Ce bug est connu ou pas?

            D'ailleurs il y a une page où sont recensés les bugs?
            • [^] # Re: Sous Debian...

              Posté par  . Évalué à 2.

              les bugs sont à rapporter sur la debian-qt-kde mailing list et tu peux trouver ceux de ce mois ci ici :
              http://lists.debian.org/debian-qt-kde/2005/03/index.html(...)

              et pour ton bug, j'ai pas l'impression que je l'ai (j'ai fait qu'un seul test, en général je supprime complètement sans passé par la case "corbeille" en utilisant shift+suppr)
              • [^] # Re: Sous Debian...

                Posté par  . Évalué à 3.

                Je fais aussi cela habituellement, mais pour un fichier qui était sur le bureau j'ai voulu passer par le menu contextuelle. Et il n'y avait plus l'option supprimer (identique à shift+suppr), je suis passé par Mettre à la corbeille, juste pour voir et j'ai eu droit à une fenêtre qui m'explique que le kioslave trash n'est pas présent.

                Après recherche, je me suis aperçu qu'il me manquait le package kdebase-kio-plugins. Après installation, trash est maintenant présent.

                Je vais jeter un coup d'oeil à la mailing list. Merci.
            • [^] # Re: Sous Debian...

              Posté par  (site web personnel) . Évalué à 0.

              >Lorsque je veux mettre un fichier dans la corbeille il me dit que le kioslave
              >trash n'existe pas.

              Ce n'est pas un bug, c'est ton installation qui est foireuse.
            • [^] # Re: Sous Debian...

              Posté par  . Évalué à 3.

              apt-get install kdebase-kio-plugins

              soit dit en passant, pour toute install kde qui se respecte, c'est mieux encore de faire :

              apt-get install kde-core

              qui t'installe kdelibs, kdebase, arts, et fontconfig et ca te permet en général d'avoir tout ce qu'il faut.

              en tout cas, moi j'ai le kio_trash installé :
              [madcoder hades] dpkg -L kdebase-kio-plugins|grep kio_trash
              /usr/lib/kde3/kio_trash.la
              /usr/lib/kde3/kio_trash.so
      • [^] # Re: Sous Debian...

        Posté par  . Évalué à 5.


        j'ai pas trop suivit pourquoi mais apparemment les mainteneurs kde ne veulent pas le mettre dans experimental mais ce dépot est à considérer comme tel (donc pas forcément parfait mais supporté et correct)


        on ne veut pas uploader dans experimental parce que tous les paquets ne sont pas prets à 100%. au niveau utilisateur ca se passe bien, mais au niveau QA debian, on a encore un peu de travail pour que ca soit vraiment parfait.

        De plus, il reste les problèmes avec kdm qu'on a pas encore eu le temps de gérer (la transition depuis kdm de 3,3,x est un peu douloureuse au niveau de la conf).

        Par contre, je pense que 3.4. ne touchera pas la sid avant un moment, vu que sid est l'entrée pour testing, et que en testing ca sera kde 3.3.2, et qu'il reste du boulot à cause des failles de sécu récentes de kde (IDN et attaque sur dcop).

        donc il y aura sans doute des uploads dans expérimental, au moins pour trigger les processing de NEW (il y a un tas de nouveaux paquets pour kde 3.4 : kttsd, akregator qui entre dans kdepim, et j'en passe)

        --
        Proud Debian KDE Packager
        • [^] # Re: Sous Debian...

          Posté par  . Évalué à 2.

          ah je t'ai vu sur la mailing list toi :)
          merci pour tout ce bon travail, les paquets marchent vraiment bien
          d'ailleurs l'idée de tout passer en cdbs est vraiment bien venu (reste kdepim si j'ai bien suivi)

          sinon pour kdm 3.4 j'avais quand même tenter le coup parce que ça me dérangeait pas de refaire la conf mais il m'a mis qu'il me manquait des widgets, tu saurais pas d'où ça vient ? (j'ai pas trouvé sur la ML)
          • [^] # Re: Sous Debian...

            Posté par  . Évalué à 1.

            > d'ailleurs l'idée de tout passer en cdbs est vraiment bien venu (reste kdepim si j'ai bien suivi)

            en fait kdepim etait deja en cdbs, mais il est maintenu par un type un peu en dehors de la team pour le moment.

            pour kdm 3.4 c'est corrigé
    • [^] # Re: Sous Debian...

      Posté par  . Évalué à 1.

      Il semblerait que pour le moment ce en soit que la pre1, mais bon, c'est deja pas mal, et ca veut dire que la release va arriver : )
      • [^] # Re: Sous Debian...

        Posté par  . Évalué à 2.

        il te semble mal. c'est la 3.4.0-0pre1

        ce qu iveut dire comme c'est apres le dash final, que c'est le *paquet* qui est en version pre1, pas son contenu, sinon ca serait 3.4.0-pre1-0 (enfin, pas tout à fait, mais c'est l'idée)

        --
        Proud Debian KDE Packager
        • [^] # Re: Sous Debian...

          Posté par  . Évalué à 3.

          hoo, toutes mes excuses, j'etais en train regarder le repo, je me suis dit que le "pre1" se trouvait etrangement derriere le -, et je me suis precipité pour voir si on etait venu m'insulter apres mon commentaire sur dlfp :>
  • # arf probleme

    Posté par  . Évalué à 1.

    bonsoir,
    je suis en train d'essayer de télécharger KDE 3.4 pour ma suse 9.2 mais lorsque je mets cette adresse ftp://ftp.lip6.fr/pub/X11/kde/stable/3.4/SuSE/ix86/9.2/(...) ds la rubrique "emplacement" pour la mise a jour en ligne, j'ai une erreur qui s'affiche "échec de l'obtention des informations sur les patches.error
    Couldn't cd to i386"

    alors que quand je tape cette meme adresse dans Konqueror, j'ai bien une liste de tous les RPM

    comment faire ?
  • # Et chez Mandrake ils font quoi ?

    Posté par  . Évalué à -1.

    Tiens c'est bizarre, j'ai pas vu passer les paquets pour Mandrake ... J'ai sûrement dû mal voir, vu que Mandrake a pour habitude de mettre, à l'image de Suse, ses paquets sur les miroirs KDE ou sur ses propres miroirs ? Comment ça, non ? On m'aurait menti ??? De quoi tu me parles là, c'est quoi ce Club, une boîte de stip-tease ???

    Pom, pom, pom ----------> []
    • [^] # Re: Et chez Mandrake ils font quoi ?

      Posté par  . Évalué à -1.

      stip-tease/strip-tease ... mais bon je pense que tout le monde avait compris ! ;-)
    • [^] # Re: Et chez Mandrake ils font quoi ?

      Posté par  (site web personnel) . Évalué à 2.

      Mandrake a pour habitude de mettre, à l'image de Suse, ses paquets sur les miroirs KDE ou sur ses propres miroirs ? Comment ça, non ?
      ¿¿¿gni???

      Concernant l'intégration de KDE 3.4, les vérifications de dépendance ne se font pas en deux secondes. KDE c'est pas ''un petit paquet''...

      Sinon, comme pour chaque distribution, tu as des paquets non officiels :
      http://rpm.nyvalls.se/(...)
      • [^] # Re: Et chez Mandrake ils font quoi ?

        Posté par  (site web personnel) . Évalué à 3.

        En meme temps les paquets Suse ils sont officiels ;)
      • [^] # Re: Et chez Mandrake ils font quoi ?

        Posté par  . Évalué à 0.

        Ouh là, ça moinsse à tout va par ici !

        Bon, visiblement tu n'as pas compris que mon propos était ironique. Mais le fait est qu'il fut une époque glorieuse (du temps de la 9.0/9.1) où Mandrake proposait des paquets du dernier KDE sur le serveur officiel de KDE. Ce temps est semble-t-il révolu depuis un moment et on peut le regrêter. Maintenant c'est réservé aux membres du Club ...
        Tu me diras : "Mandrake est une distribution commerciale". Ok, mais Suse aussi et leurs paquets officiels sont toujours dans les premiers sur kde.org ! Voilà, c'est là où je voulais en venir ...

        Pour le reste on est d'accord, KDE c'est pas simple à intéger et à tester et en ce moment les petits gars de Mandrake sont bien pris par la future 10.2. Il y avait volontairement un peu de provoc dans mon post et visiblement ça a bien marché ! ;-)

        Pour ce qui est des paquets KDE non officiels de Thac ... hum ... joker !
        • [^] # Re: Et chez Mandrake ils font quoi ?

          Posté par  . Évalué à 0.

          > Ouh là, ça moinsse à tout va par ici !

          C'est vraiment trop injuste. Mon pauvre petit Kalimero.

          M'enfin, t'as pas tord.

          J'ai une idée (histoire que tu ne sois pas le seul à être moinsé) :
          - laisses tomber Mandrake
        • [^] # Re: Et chez Mandrake ils font quoi ?

          Posté par  . Évalué à 7.

          Tu oublies quelque chose : le support de l'internationalisation est bien plus complet chez Mandrakelinux que chez Suse. KDE 3.4 est peut-etre sorti, mais pas toutes les traductions, qui ont souvent du retard. Le probleme s'etait egalement pose avec KDE 3.3. Il n'avait pas pu etre integre pour les memes raisons, d'une part le manque de tests 7 a 15 jours avant la release (d'ailleurs KD 3.4 est parait-il fortement buggue dans la Fedora Core 4 rc), d'autre part le manque de support des langues. Eh oui, tout le monde ne parle pas anglais ou francais.

          D'autre part tes insinuations sur le club sont completement gratuites. Tu ne sais absolument pas quand et comment ces paquets seront distribues. On a eu exactement les memes remarques a propos de la x86_64. Cette fois, des isos vont etre publics (en sus des miroirs FTPs deja disponibles, ainsi que les outils permettant de fabriquer ces isos). C'est facile de taper, mais au moins il faut etre sur de ce que l'on affirme pour eviter de passer pour un aigri.

          Par ailleurs, pour ce qui est du club, j'en fais partie en effet. Mais tu sais quoi ? Sans jamais avoir debourse un seul sou. Il suffit de maintenir quelques paquets dans les contributions, ou bien participer a l'ecriture des docs, ou bien moderer le club, etc... Le commercial ne signifie pas forcement de l'argent.
          • [^] # Re: Et chez Mandrake ils font quoi ?

            Posté par  . Évalué à 1.

            > Tu oublies quelque chose : le support de l'internationalisation est bien plus complet chez Mandrakelinux que chez Suse. KDE 3.4 est peut-etre sorti, mais pas toutes les traductions, qui ont souvent du retard.

            Mauvaise raison. Il y a plus de traduction dans KDE 3.4 que dans KDE 3.3.
            Le src.rpm de kde-i18n de KDE 3.3 pèse 176 Mo celui de KDE 3.4 243 Mo.
            Les traducteurs ne sont pas mainteneurs. Ils bossent sur la version upstream et font en sorte que les nouvelles soient les plus complètes possibles.
            Enfin, à ma connaissance Mandrake ne s'occupe pas de l'internationalisation de KDE. Pour KDE ils ne font aucun travail spécifique sur la traduction (ou alors c'est très très limité).

            > Le probleme s'etait egalement pose avec KDE 3.3.

            Mauvaise réponse.
            Globalement Mandrake fait le choix de baser ses distributions sur des solutions éprouvées (ça n'a pas toujours été le cas). Je ne dis pas que c'est un mauvais choix mais c'est un choix de Mandrake et qu'il faut assumer.
            Fedora fait le choix "d'aller de l'avant" d'être là où les choses se passent (en bien et en mal).
            Ça se voit sur les plannings. Je dirais presque que Mandrake fait en sorte que les nouvelles versions de KDE/Gnome sortent trop tard pour leur planning. Fedora repousse le planning si nécessaire. La démarche est complètement différente.
            Puis je ne serais pas étonné que Mandrake réserve KDE 3.4 aux "clubbers".

            > d'ailleurs KD 3.4 est parait-il fortement buggue dans la Fedora Core 4 rc

            T'es charmant. Déjà il n'y a pas de rc de FC4. Il y a la test 1 (la version finale est pour début juin). C'est la toute première beta et donc forcément il y a des bugs et même beaucoup (pas forcément liés à KDE).
            FC4T1 a kde 3.4.0-rc1 et pas la version finale de kde. La version finale de KDE 3.4.0 sera dans Rawhide aujourd'hui ou demain.
            Les paquets KDE 3.4 pour Fedora dispos sur kde.org sont fait par un employé Red Hat. C'est une iniative personnelle.
            Mandrake, son épique, ne veut pas ou ne peut pas le faire. Faut assumer.

            > D'autre part tes insinuations sur le club sont completement gratuites.

            Ce n'est pas gratuit. Mandrake a décidé pour KDE 3.3 de le fournir en exclusivité pour les membres payants (boîte ou club). C'est le choix de Mandrake donc Mandrake est critiquable. Partant de ça, Mandrake a peut-être de bonnes raisons et c'est sur ces raisons que tu pourrais éclairer les gens au lieu de dire n'importe quoi.

            > On a eu exactement les memes remarques a propos de la x86_64. Cette fois, des isos vont etre publics

            Donc tu démontres que les critiques/remarques/mécontentements étaient justifiées.
            Red Hat fait le choix de ne pas fournir RHEL en binaire gratuitement. Red Hat se fait critiquer et donc il faut justifier ce choix avec de bons arguements. Ben pour RHEL comme pour x86_64 de Mandrake ou KDE 3.3 uniquement pour les "clubbers" c'est pour des raisons de business/pognon et pas des raisons de i18n ou je ne sais quoi d'autre.

            Je ne dis pas que le pognon c'est mal(tm). Mais seulement qu'il faut assumer les choix qui sont faits. Et les assumer dans les deux sens. RHEL payant permet d'avoir Fedora gratuit et Mandrakeclub, etc permet d'avoir MandrakeLinux gratuit.

            C'est dingue, je n'utilise pas KDE mais là je suis obligé de défendre KDE.
            • [^] # Re: Et chez Mandrake ils font quoi ?

              Posté par  . Évalué à 5.

              >Mauvaise raison. Il y a plus de traduction dans KDE 3.4 que dans KDE 3.3. Le src.rpm de kde-i18n de KDE 3.3 pèse 176 Mo celui de KDE 3.4 243 Mo.

              C'est vrai que la taille des fichiers i18n est un gage d'asurance qualite. On n'a plus besoin de tester: hop, il y a 100Mo de plus, ca veut dire qu'on peut les integrer 15 jours avant la release.

              > Donc tu démontres que les critiques/remarques/mécontentements étaient justifiées. [...] Red Hat se fait critiquer[...]

              Ca ne demontre absolument rien. Je n'ai d'ailleurs jamais critique RHEL, c'est libre. Ce que tu ne comprends pas c'est que je ne cherche pas a rentrer dans une guerre de distro. Comme a ton habitude, tu cherches toujours a opposer Mdk et RH, mais moi pas, ca ne m'interesse pas. Chacun est libre d'utiliser ce qu'il veut. Mon exemple pris avec KDE dans la Fedora n'etait pas une pique contre Fedora, mais pour souligner qu'integrer KDE 3.4 etait risque 15 jours avant la release.

              >Et les assumer dans les deux sens. RHEL payant permet d'avoir Fedora gratuit et Mandrakeclub, etc permet d'avoir MandrakeLinux gratuit.

              J'ai jamais dit le contraire. Ce qui m'importe, c'est le respect du libre. Or Mandrake en a toujours respecte les principes. Ils ont toujours respecte les regles du libre, et je n'ai pas eu de probleme a faire accepter mes paquets en tant que contributeur. Les sources sont toujours accessibles, les binaires sont dispos parfois sous forme d'isos, toujours sous forme d'une branche FTP, avec les outils permettant de creer les CDs. Je ne pense pas qu'on puissse faire beaucoup mieux, surtout de la part d'une boite qui sort a peine de la cessation de paiement.

              Peut-etre qu'un jour tu comprendras que des gens aiment utiliser telle ou telle distro, ou plusieurs, sans avoir sur le dos des personnes pour les critiquer, les juger, troller...
              • [^] # Re: Et chez Mandrake ils font quoi ?

                Posté par  . Évalué à -1.

                > Comme a ton habitude, tu cherches toujours a opposer Mdk et RH, mais moi pas, ca ne m'interesse pas.

                Tu parle de SuSE et Fedora et après tu fais la leçon.
                T'as le moral toi.

                > Ce qui m'importe, c'est le respect du libre. Or Mandrake en a toujours respecte les principes. Ils ont toujours respecte les regles du libre, et je n'ai pas eu de probleme a faire accepter mes paquets en tant que contributeur.

                C'est pas le sujet du thread. Le sujet est une personne qui se plaint que KDE 3.4 n'est pas dispo pour Mandrake (realese actuel et la prochaine release) et qu'il sent que KDE 3.4 sera uniquement dispo pour les clubbers.

                > Peut-etre qu'un jour tu comprendras que des gens aiment utiliser telle ou telle distro, ou plusieurs, sans avoir sur le dos des personnes pour les critiquer, les juger, troller...

                Peut-être qu'un jour tu répondras aux interrogations légitimes des gens au-lieu de faire systématiquement de la pub à 2 balles.
                Ton post n'a absolument rien apporté à ce thread.
                • [^] # Re: Et chez Mandrake ils font quoi ?

                  Posté par  . Évalué à -1.

                  Il a plutôt une bonne note, pour un post qui « n'a absolument rien apporté à ce thread ».

                  Visiblement, tout le monde ne partage pas ton avis.
            • [^] # Incroyable...

              Posté par  . Évalué à -7.

              À la lecture du commentaire de fabb et en considérant sa note actuelle négative, je m'interroge.

              Alors soit il y a vraiment un foutu paquet d'imbéciles qui ont le pouvoir de noter et qui ne s'en privent pas (auquel cas, il serait bon qu'il s'interroge sur le sens des mots « pertinent » et « inutile »), soit il y a sur ce site un fort lobbying de soutien à Mandrakelinux.

              Dans les 2 cas, ce serait extrêmement puant, et particulièrement bas.

              Tant que j'y suis, vous pouvez doublement inutilisanter mon commentaire, parce qu'après avoir acheté 5 PowerPack Mandrakelinux, 1 Mandrakelinux AMD64, et 3 Mandrakelinux Discovery, j'ai décidé de ne plus acheter de packs Mandrake pour le moment (tant que je ne verrais pas un changement significatif dans ce qui ne me convient pas du moins) et de ne pas renouveller mon abonnement au MandrakeClub, et très certainement de ne plus participer à l'avenir au bug-reporting auquel je me livrais jusqu'à présent sur ma MandrakeCooker.
              • [^] # Re: Incroyable...

                Posté par  . Évalué à 2.

                Et ?
                Tu es libre de faire ce que tu veux. C'est ca Linux, la liberte. On dirait qu'on vous a forces a utiliser Mandrake et que maintenant, tels des "freedom fighters", vous devez partir en croisade contre cette distro.
                • [^] # Re: Incroyable...

                  Posté par  . Évalué à 8.

                  Personne ne m'a forcé à utiliser Mandrakelinux en effet, j'ai même été très content de découvrir linux grâce à cette distribution.

                  Cela dit, depuis que je l'ai découverte, pas mal de choses ont changé. Peut-être que ces changements sont du fait des ennuis financiers rencontrés, toujours est-il que désormais certaines pratiques de Mandrakesoft ne me conviennent plus vraiment, par exemple :

                  - MandrakeMove version download qui est bridée
                  - Mandrakelinux version download qui n'est disponible qu'1 ou 2 mois après la sortie pour le MandrakeClub
                  - Mandrakelinux AMD64 qui n'était pas disponible sous forme d'iso à moins de payer le prix fort (199 ¤ il y a quelques mois à peine)

                  De même, le support matériel et certains bogues laissent vraiment à désirer depuis quelque temps :

                  - Sound Blaster Live! très mal supportée (pas reconnue par alsa, puis problème de reconnaissance par le kernel, puis reconnue à nouveau mais pas de son avec les jeux et flash, etc.)
                  - support de l'ACPI désastreux
                  - problème de support de nombreux lecteurs de DVD, dont les Pioneer (qui n'existe pas avec d'autres distribs)
                  - Drakconf qui plante sur le splashscreen (et une mandrake sans drakconf, c'est quoi pour un débutant ?)

                  Sinon, dans l'ensemble, les choix Mandrake sont aussi assez incohérents :

                  - Support de KDE comme environnement par défaut mais applications Gnome ou GTK (evolution, totem, etc.) définies comme applications par défaut.
                  - Outils Drak* qui pourraient au moins bénéficier d'une interface en QT

                  Bon, je m'arrête là, mais je pense que tu auras saisi en gros le pourquoi de mes critiques. Le vrai problème, c'est que le fait de critiquer Mandrakelinux t'expose, même en apportant des arguments, t'expose à un inutilisantage quasi-systématique, et à des commentaires débiles du genre « chez moi ça marche donc t'es qu'un gros naze », voire à d'autres encore pire « où sont tes bug reports » (génial, surtout quand tu as payé 199 euros le pack AMD64 pour pas être emmerdé justement)

                  Le vrai problème, ce n'est pas Mandrakelinux, mais la communauté d'irréductibles imbéciles présents sur ce site et qui font un lobbying très appuyé en faveur de cette distribution.

                  Il n'est pas question d'une croisade contre cette distro, mais de faire en sorte que la critique soit équitable entre toutes les distributions, et que ces critiques remontent à Mandrakesoft. J'ai encore en mémoire les critiques acerbes envers SuSE et Red Hat, notamment lorsque Red Hat innovait sur pas mal de choses, et que ses choix étaient vivement critiqués ici-même par les utilisateurs Mandrake, pour qu'au final Mandrakelinux suive, toujours après, une fois que les choix techniques avaient été imposés et éprouvés.

                  Au final, on voit ce que ça a donné : SuSE a été la première distribution à sortir une version 64 bits, et est la seule à être certifiée LSB 2.0, Fedora FC3 et encore plus FC4 intègre déjà des nouvelles technologies qui sont pas encore présentes chez Mandrake, et qui le seront forcément à l'avenir.

                  Donc le coup des « freedom fighters » a bon dos, parce que j'ai plutôt l'impression que la mauvaise foi se fait dans l'autre sens.
                  • [^] # Re: Incroyable...

                    Posté par  (site web personnel) . Évalué à 4.

                    apportant des arguments, t'expose à un inutilisantage quasi-systématique, et à des commentaires débiles du genre « chez moi ça marche donc t'es qu'un gros naze

                    Oui, sauf qu'ici tes remarques sont constructives, ce qui n'est pas toujours le cas dans tes commentaires (par exemple faire un journal pour se plaindre de la Mandrake en version Cooker).

                    chez moi ça marche donc t'es qu'un gros naze

                    C'est stupide, mais autant que chez moi ça ne marche pas donc c'est de la
                    Merde, qui revient à faire des généralités avec sa machine.

                    support de l'ACPI désastreux.
                    Drakconf qui plante sur le splashscreen


                    chez moi ça marche ; -)
                    • [^] # Re: Incroyable...

                      Posté par  . Évalué à 2.

                      Oui, sauf qu'ici tes remarques sont constructives, ce qui n'est pas toujours le cas dans tes commentaires (par exemple faire un journal pour se plaindre de la Mandrake en version Cooker).


                      Attention de ne pas confondre, si j'ai fait un journal, ce n'est pas parce que ma MandrakeCooker a eu un problème, mais parce que 3 versions différentes de Mandrakelinux, sur 3 machines différentes, ont connu le même genre de problème ( http://linuxfr.org/comments/547209.html#547209(...) ).

                      Il s'avère qu'après en avoir discuté sur la tribune et avoir googlisé, beaucoup d'utilisateurs Mandrakelinux ont rencontré ce genre de problème avec ext3fs, et que le ext3fs de Red Hat est fortement patché.

                      Je ne suis donc pas en mesure de savoir, à l'heure actuelle, si la faute incombe à Mandrakesoft ou à ext3fs, et c'est donc la raison pour laquelle je n'ai pas encore posté ce fameux journal que certains attendent encore, parce que contrairement à ce que certains ont l'air de penser, mon but n'est pas de critiquer Mandrakelinux aveuglément, bien au contraire.

                      Après tu conviendras que 3 crash de système de fichiers sur 3 machines différentes en moins de 1 an, il y a de quoi s'énerver, même si tu as des sauvegardes, parce que cela ne m'est jamais arrivé personnellement en presque 10 ans de NTFS ! :-)
                      • [^] # Re: Incroyable...

                        Posté par  . Évalué à 4.

                        > le ext3fs de Red Hat est fortement patché.

                        Non. Les src.rpm sont à dispositions, tu peux vérifier. Par contre Red Hat est le principale développeur/mainteneur de ext3 et lorsqu'il développe une nouvelle fonctionnalité elle est en premier testé largement sur Fedora (durant les phases beta) puis remonté en upstream.
                      • [^] # Re: Incroyable...

                        Posté par  (site web personnel) . Évalué à 3.

                        Après tu conviendras que 3 crash de système de fichiers sur 3 machines différentes en moins de 1 an, il y a de quoi s'énerver, même si tu as des sauvegardes, parce que cela ne m'est jamais arrivé personnellement en presque 10 ans de NTFS ! :-)

                        Mais qui te forçait à utiliser ext3? Quand un truc déconne, faut pas être très malin pour le s'acharner à le réutiliser. Il y a plein d'autres systêmes de fichiers sous linux. J'utilise xfs depuis des années, j'ai jamais eu le moindre problème. J'ai voulu retester ext3 y a pas longtemps, en un mois, j'ai eu 2x des données corrompues(sur debian et mandrake). Je ne commence pas à gueuler partout que ces distros suxent(ou alors, pas pour cette raison)
                        • [^] # Re: Incroyable...

                          Posté par  . Évalué à 2.

                          Mais qui te forçait à utiliser ext3?


                          Mandrake ? Je rappelle que ext3fs est le choix par défaut de Mandrakelinux, et que ce choix est conservé par la grande majorité, notamment par les nouveaux venus à Linux.

                          Quand un truc déconne, faut pas être très malin pour le s'acharner à le réutiliser. Il y a plein d'autres systêmes de fichiers sous linux


                          On est bien d'accord, mais comme je l'indique, les pannes se sont produites à quelques mois d'intervalle, et jusque là, rien ne laisser présager que le choix par Mandrake était *merdique*. Par contre, il est évident que pour moi, ext3fs c'est fini.

                          Je ne commence pas à gueuler partout que ces distros suxent(ou alors, pas pour cette raison)


                          Là où j'ai gueulé sur Mandrake suite à ce crash de fs, c'est que les outils de récupération made-in-Mandrake font encore plus de dégâts que le crash lui même !

                          En tout cas, je note que visiblement le problème n'est pas spécifique à Mandrakelinux (puisque tu l'as connu aussi sous Debian), et que donc, il me faut vraiment définitivement abandonner ext3fs :-)
                          • [^] # Re: Incroyable...

                            Posté par  . Évalué à 0.

                            > il me faut vraiment définitivement abandonner ext3fs :-)

                            Tu devrais réfléchir un peu.
                            Recherche google "ext3" and "corrupted" : 23 300
                            Recherche google "reiserfs" and "corrupted" : 21 000
                            Recherche google "xfs" and "corrupted" : 14 700

                            Sachant que ext3 est le plus utilisé et de loin, tu devrais y réfléchir un peu plus.
                            Pour info :
                            Recherche google "ntfs" and "corrupted" and not "linux" : 59 300

                            Il semble que tu n'as pas lu ma réponse à un de tes commentaires dans un journal.
                            http://linuxfr.org/comments/548899.html#548899(...)
                            • [^] # Re: Incroyable...

                              Posté par  (site web personnel) . Évalué à 2.

                              Perso, ext3fs, j'ai eu que des merdes et je continue à avoir que des merdes(pas sur mes machines). Ca permet au passage de convaincre les gens de passer à xfs...

                              Des que t'as une installation éléctrique qui fatigue, ext3 n'est pas un bon choix, sauf si tu veux te retrouver avec tes partoches dead de chez dead.
                              • [^] # Re: Incroyable...

                                Posté par  . Évalué à 1.

                                Les conneries de chez connerie il faut calmer un peu.
                                Si ext3 c'est de la merde, il ne serait pas utilisé si massivement.

                                Un test ext3/reiserfs/xfs/jfs :
                                https://www.redhat.com/archives/fedora-list/2004-July/msg00418.html(...)
                                The test is really pretty simple. It is hooked to a machine that cycles the power. It runs for 5 minutes and then the power is turned off for 1 minute (to simulate the plug being pulled). For this last set of tests it has 3 hard drives connected, one Parallel IDE and two Serial ATA. The system boots a minimal install of Fedora Core 2 from the IDE drive. No tests are running on the IDE drive. In the rc.local file it starts the fsstress test http://ltp.sf.net/nfs/fsstress.tgz(...) and the three scripts below (to simulate writing into a log file) on each of the SATA drives.

                                The ext3 have almost a perfect record with the write cache off: I have run over 300 cycles on the two drives and only had two corrupted lines in the output files. So out of 600 total cycles on the two drives there were only two lines with bad data, I think that is a pretty good record.[1]

                                None of the other journaling file systems have come anywhere near this performance. After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there). XFS never got corrupted to the point it wouldn't boot, but with approximately 100 power cycles on each drive, one drive had 73 corrupted lines and the other had 82. With JFS after 15 power cycles one of the drives was corrupted and the system would no longer boot up (fsck failed again).

                                I just can't understand what is happening, it makes no sense to me that one file system would be almost perfect and three would fail so dramatically. I am going to re-run the tests on all 4 file systems to verify that it is repeatable.

                                Should I report these problems to the upstream projects (Reiser, XFS, JFS)?


                                [1] Ce problème des 2 lignes perdus est "normal". Il est expliqué par Alan Cox plus loin.
                                • [^] # Re: Incroyable...

                                  Posté par  (site web personnel) . Évalué à 1.

                                  bon moi aussi j'abandonné le ext3 sous mandrakedepuisla 9.0 où j'avais perdu des données.... (3fois le /usr de suite, ça calme...)

                                  Depuis j'utilise quotidiennement et j'ai eu un soucis très récementsur le / (pas de xfs_repair sur le / depuis des mois et 8 freeze du system ont eu raison de lui...)

                                  Donc je recommande xfs MAIS il faut faire du xfs_repair (très chiant) régulièrement sinon on risque de perdre des données...
                                  Cela est du au fsck.xfs qui est un int main {return 1}
                                  Je vais conder un patch pourque le fsck.xfs marche au démarage et évite trop de démarage avec des partoche crashés


                                  /!\ Je n'ai perdu aucune donnée dans mon /home et dans toutes mes autres partoches de données... Donc xfs on continue...
                                  • [^] # Re: Incroyable...

                                    Posté par  . Évalué à 1.

                                    > bon moi aussi j'abandonné le ext3 sous mandrakedepuisla 9.0

                                    Apparament la majorité des problèmes ext3 sont sous Mandrake.
                                    J'invite les gens à fouiller les mailings et le bugzilla de Red Hat. Les problèmes ext3 sont rares (mais ils existent).

                                    Je l'ai déjà dit ailleur, mais des problèmes avec ext3 ont déjà été rencontré alors qu'il ne sont pas liés à ext3 mais à des drivers qui foutent le bordel dans la mémoire du noyau. Mandrake ajoute beaucoup de driver et peut-être qu'à certaines époques celà a affecté ext3.
                  • [^] # Re: Incroyable...

                    Posté par  . Évalué à 2.

                    Sinon, dans l'ensemble, les choix Mandrake sont aussi assez incohérents :

                    - Support de KDE comme environnement par défaut mais applications Gnome ou GTK (evolution, totem, etc.) définies comme applications par défaut.
                    - Outils Drak* qui pourraient au moins bénéficier d'une interface en QT


                    Entièrement d'accord sur Drakconf &co, mais totem ou évolution par defaut, c'est pas dans la 10.2 en tout cas.

                    Le vrai problème, ce n'est pas Mandrakelinux, mais la communauté d'irréductibles imbéciles présents sur ce site et qui font un lobbying très appuyé en faveur de cette distribution.


                    On peut aussi se plaindre du contraire, le journal annonçant KDE 3.4 parlait presque exclusivement du manque de cette version dans la futur mandrake...

                    Au final, on voit ce que ça a donné : SuSE a été la première distribution à sortir une version 64 bits, et est la seule à être certifiée LSB 2.0,


                    Oui mais la LSB2 ...

                    Fedora FC3 et encore plus FC4 intègre déjà des nouvelles technologies qui sont pas encore présentes chez Mandrake


                    Fedora est une sorte de RedHat en version Beta, donc c'est pas étonnant.

                    Mandrake à passer pas mal de temps à faire un KDE3.3 stable, et ils ont porté les choses les plus intéréssantes de 3.4 dans 3.3 (Kpdf..).
                    • [^] # Re: Incroyable...

                      Posté par  . Évalué à 1.

                      > Fedora est une sorte de RedHat en version Beta, donc c'est pas étonnant.

                      Ce troll récurrent... Pénible.
                      Fedora n'est pas une beta. C'est le lieu où Red Hat et d'autres mijotent des évolutions techniques. C'est fait en phase beta de Fedora ou dans Rawhide. Si ça marche c'est activé en version finale si ça ne marche pas c'est désactivé. Ainsi pour FC2, selinux était présent mais désactivé car il y avait encore trop de problème et pour FC3 selinux est présent et activé.
                      Pourquoi ce n'est pas fait avec RHEL ?
                      Car RHEL n'est pas un bon cadre pour ça. Si on veut attirer des contributeurs il est de bon ton de le faire sur un produit gratuit et "communautaire". RHEL est basé sur Fedora mais n'a pas pour objectif de faire avancer le libre mais "uniquement" pour satisfaire ses clients.
                      De plus Fedora permet à Red Hat d'avoir des feedback des utilisateurs *avant* de proposer un produit. C'est ainsi (parmis plein d'autres choses) que les règles targeted pour SeLinux ont été faite pour Fedora (et RHEL) et que FireFox est le navigateur par défaut alors que Red Hat voulait initialement rester sur epiphany, que Red Hat est passé d'un panel dans gnome à deux, etc.
                      Red Hat peut se permettre d'être "audacieux" avec Fedora mais pas avec RHEL. Ceci n'empêche pas de faire de la fiabilité un critère important de Fedora.
                      Red Hat n'a aucun intérêt de faire de Fedora une sorte beta-produit car c'est la base de RHEL. Meilleur est Fedora, meilleur est RHEL. Red Hat l'a très bien compris.
                  • [^] # Re: Incroyable...

                    Posté par  (site web personnel) . Évalué à 1.

                    Le probleme d'alsa a été un bug majeur de la 10.0 et 10.1 il me semble. Sou ma cooker jai pas eu de pb, sauf depuis le passage au kernel 2.6.11 qui s'est soldé par des gros pb (snd-emu10k1 qui planteet pas mal d'autre soucis).

                    J'ai opté sur la solution de rester perpétuellement en cooker pour voir mes bugs corrigés rapidement, après c'est le choix de chaqu'un, les versions "stables" de MandrakeLinux ont eu de gros soucis de stabilité chez moi (plantages aléatoires etc...), mais ce qui me plaît c'est que ça samméliorre au fur et a mesure donc je me pleind pas...

                    Ps : tu passe sous silence pas mal de truc que fait mandrake
                    Outil simple de config de service (bon config minimale ok)
                    Menu pas "dégeulasse" et rangé, pas comme sous d'autre distrib
                    Pas besoin de se prendre la tête avec des truc désactivé pour raison de secu parano, bien que parfois...
                    Et plein d'autre truc que j'oublie surement...

                    Allez urpmi.update -a && urpmi kernel-2.6.11.3mdk
                    pas de paquetage nommé kernel-2.6.11.3mdk

                    Et merde pas encore corrigé, bon on va rester en
                    kernel-multimedia-2.6.10-3.mm.4mdk-1-1mdk...

                    Allez un effort mandrake, la correction de ce bug serait pas de refus...
                  • [^] # Re: Incroyable...

                    Posté par  . Évalué à 0.

                    SuSE a été la première distribution à sortir une version 64 bits

                    Ah bon.
                  • [^] # Re: Incroyable...

                    Posté par  (site web personnel) . Évalué à 3.

                    désormais certaines pratiques de Mandrakesoft ne me conviennent plus vraiment

                    MandrakeSoft est une entreprise commerciale. Son but, comme toutes entreprsies commerciales, c'est de gagner de l'argent. Elle trouve divers moyens pour ça comme par exemple Mandrakelinux version download qui n'est disponible qu'1 ou 2 mois après la sortie pour le MandrakeClub.

                    Et alors? Moi ça me choque pas. Parce que MandrakeSoft a toujours respecté, depuis le début, et même dans les difficultés financières, le logiciel libre. Ce qui n'est pas le cas de SuSE avant le rachat par Novell, par exemple.

                    Support de KDE comme environnement par défaut mais applications Gnome ou GTK (evolution, totem, etc.) définies comme applications par défaut.

                    Et alors? Je pense que ce serait absurde de prétendre que toutes les applications KDE ou en Qt sont meilleures que celles de GNOME ou en GTK. Par exemple, Gaim me semble plus abouti que Kopete. Ce serait aussi pas très malin de ne pas inclure Gimp ou GnomeMeeting parce que c'est pas du KDE. Bref, on peut vouloir mettre du KDE et pas être complétement avec des oeillieres.

                    - Outils Drak* qui pourraient au moins bénéficier d'une interface en QT

                    Mais du coup on serait obligé d'installer Qt.
                    • [^] # Re: Incroyable...

                      Posté par  . Évalué à 3.

                      > Ce qui n'est pas le cas de SuSE avant le rachat par Novell, par exemple.

                      Faut peut-être pas pousser. SuSE n'avais "que" yast avec une licence "bizarre". Le principale problème de la licence était de ne pas permettre un usage commercial.

                      Mandrake vend des produits proprio via MandrakeClub. Mandrake fournit le compilateur proprio d'Intel. Mandrake ne contribue en presque rien au logiciel libre en upstream (par rapport à SuSE, c'est le jour et la nuit). Mandrake ne fournit presque rien en ressource (hébergement de projet libre, etc).

                      SuSE a choisi une voie différente de Mandrake mais lorsqu'on fait le bilan on ne peut que se féliciter de la contribution de SuSE au logiciel libre.

                      Je n'utilise ni SuSE ni Mandrake. Mais je vois/apprécie les contributions de SuSE et je ne vois presque jamais les contributions de Mandrake.
                      • [^] # Re: Incroyable...

                        Posté par  . Évalué à 3.

                        >je ne vois presque jamais les contributions de Mandrake.

                        Vraiment ? Quel troll. Les contributions sont sur le wiki :
                        http://qa.mandrakesoft.com/twiki/bin/view/Main/FreeSoftwareProjects(...)

                        Mais evidemment, on peut leur reprocher de ne pas se vanter. Certains parlent beaucoup, d'autres agissent.
                        • [^] # Re: Incroyable...

                          Posté par  . Évalué à 1.

                          > Certains parlent beaucoup, d'autres agissent.

                          Mais oui.

                          Pour la vantardise, trouves une page Red Hat ou Novell qui recense leurs contributions car je ne connait pas une telle page.

                          Pour ton info voilà les contributions de Mandrake pour Linux 2.6 (sur plus d'un an ! ) :
                          <tvignaud@mandrakesoft.com>
                          [PATCH] checksatck.pl fixes

                          - "\<" and "\>" can be safely replaced with "<" and ">"

                          - "$var =~ /^string$/" is better written "$var eq 'string'"

                          - $i is better written without the double quotes

                          - it's not safe to use for without "my"ing the iteration variable

                          - "print foreach @array" is better written "print @array"

                          - declare variables

                          - ".*" is useless at the end of a regexp

                          - "$a[@a] = $foo" is a rather obfuscated syntax for "push @a, $foo"...
                          let's not opencoding language basic operators...

                          - ignoring return value from a regexp is very bad: this can results in
                          working on previous value of $1, $2, ...


                          <tvignaud@mandrakesoft.com>
                          [PATCH] fix compiling oldconfig with gcc-3.5

                          fix compiling oldconfig with gcc-3.5:


                          Comparaison :
                          [admin@one tmp]$ grep -i "^<.*osdl" ChangeLog-2.6.* | wc -l
                          4702
                          [admin@one tmp]$ grep -i "^<.*suse" ChangeLog-2.6.* | wc -l
                          1477
                          [admin@one tmp]$ grep -i "^<.*redhat" ChangeLog-2.6.* | wc -l
                          1054
                          [admin@one tmp]$ grep -i "^<.*ibm" ChangeLog-2.6.* | wc -l
                          863
                          [admin@one tmp]$ grep -i "^<.*intel" ChangeLog-2.6.* | wc -l
                          621
                          [admin@one tmp]$ grep -i "^<.*debian" ChangeLog-2.6.* | wc -l
                          159
                          [admin@one tmp]$ grep -i "^<.*gentoo" ChangeLog-2.6.* | wc -l
                          11
                          [admin@one tmp]$ grep -i "^<.*mandrake" ChangeLog-2.6.* | wc -l
                          2

                          Mandrake ne fait pas parti des nombreux membres de OSDL.
                          • [^] # Re: Incroyable...

                            Posté par  . Évalué à 2.

                            Ce n'est pas parce qu'ils ne hackent pas le kernel qu'ils ne participent pas au logiciel libre. Le logiciel libre se resume uniquement au kernel ? Car j'avais lu dans ton message que "Mandrake ne contribue en presque rien au logiciel libre en upstream", mais peut-etre que je me suis trompe.
                            • [^] # Re: Incroyable...

                              Posté par  . Évalué à 1.

                              > Le logiciel libre se resume uniquement au kernel ?

                              Très bien. Regarde toi même du côté de gcc/libc/gnome/kde/xorg et Mandrake est toujours un nain.
                              J'en veux pas à Mandrake mais j'en ai marre du pipeau qui répète que Mandrake est un gros contributeur alors que ce n'est pas le cas. Mandrake est un petit contributeur.
                              Le plus gros travail de Mandrake est de packager une distribution (comme beaucoup d'autres distributions).
                              Le plus gros travail de Red Hat ou SuSE est de développer des nouvelles fonctionnalités en upstream puis de les packager.
                              Je répète, je n'en veux pas Mandrake. C'est une petite boîte et packager une distribution c'est beaucoup de boulot pour leur effectif. Les effectifs de Red Hat ou SuSE étant beaucoup plus important (un rapport de 10) et sachant qu'ils ne font pas plus de distribution que Mandrake il est normal qu'ils aient du temps pour faire autre chose que "seulement" packager une distribution.
                              J'en ai marre du pipeau "Mandrake est un gros contributeur".
                              • [^] # Re: Incroyable...

                                Posté par  . Évalué à 4.

                                >J'en ai marre du pipeau "Mandrake est un gros contributeur".

                                Tu as l'air de me reprocher cela, alors que je ne l'ai jamais ecrit.
                                Mandrake emploie l'un des codeurs de KDE (pour couper court: kde-base, pas une appli satellite). Il y a aussi Warly, qui code un cdrecord libre capable de graver les DVD. Il y a aussi la completion auto dans bash, etc... Ce n'est pas "gros" pour certains (encore que la gravure des DVD ce n'est pas rien), mais beaucoup pourraient aussi ecrire qu'ils en ont marre de lire qu'ils ne font presque rien pour le logiciel libre, hein.
                    • [^] # Re: Incroyable...

                      Posté par  . Évalué à 4.

                      Par exemple, Gaim me semble plus abouti que Kopete.

                      Mmmh, je n'ai pas dû utiliser Gaim depuis longtemps alors (et pourtant je ne jurais encore que par lui il y a une paire de mois). Parce que Kopete, au moins sur KDE3.3 (à plus forte raison en 3.4) lui tient la dragée haute. Je pense notamment au "browsing" des fonctionnalités Jabber, qui m'ont toujours terriblement manqué dans Gaim.

                      Qui plus est, vouloir faire un bureau KDE avec Gaim comme IM, ça serait limite balot, vu comme Kopete est bien intégré au reste de KDE (Kontact, tout ça).
          • [^] # Re: Et chez Mandrake ils font quoi ?

            Posté par  (site web personnel) . Évalué à 4.

            Marrant, ça... J'utilise plusieurs distributions de Linux, même des "outsiders" comme Sentinix ou e-smith, et jamais il ne me viendrait à l'idée de taper sur une distrib, commerciale ou non. Pourtant, c''est incroyable ce que Mandrake peut s'en prendre plein la gueule. Même si on préfère une autre distribution, on peut en faire la promo sans se défouler sur Mandrake...
          • [^] # Re: Et chez Mandrake ils font quoi ?

            Posté par  . Évalué à 0.

            Bien, heureux d'apprendre qu'il y aura des isos publics pour la x86_64, je ne peux que féliciter Mandrake pour cette initiative, qui n'est jamais qu'un alignement sur ce que font les autres principales distributions (Fedora, Debian/Ubuntu, Gentoo, et même si je ne me trompe Suse).

            Pour le reste, Mandrake s'oriente de plus en plus vers du "libre à deux vitesses", l'ADSL pour les membres du Club (qui payent pour ça) et le 56K pour les autres. Je trouve que c'est un peu dommage, mais il est vrai que le Club représente (du moins actuellement) la majeur partie de ses revenus. C'est d'autant plus dommage que le nouveau mode de développement de la Mandrake (Community avant Official) fait largement appel aux béta-testeurs de tous poils, pour un résultats dont seul les membres du Club bénéficient en primeur (et je ne pense pas qu'un ou deux rapports de bug suffisent pour se voir offrir un accès gratuit au Club)...

            Sinon pour ton idée de maintenir quelques paquets, je suis pas sûr qu'un gars qui n'a jamais tapé une ligne de C/C++ de sa vie (par contre le Fortran c'était vraiment top ! ;-) ) soit très compétent pour ça. Après il se trouverait toujours des grincheux pour dire que Mandrake c'est de la merde et que les paquets non-officiels sont tous pourris ! ;-))))
            • [^] # Re: Et chez Mandrake ils font quoi ?

              Posté par  . Évalué à 2.

              >Pour le reste, Mandrake s'oriente de plus en plus vers du "libre à deux vitesses", l'ADSL pour les membres du Club (qui payent pour ça) et le 56K pour les autres.

              Je pense que toutes les distros sont dans cette situation. Le DVD iso de Suse n'est pas vraiment accessible au 56K non plus :) Par contr tu peux commander des CDs directement a Mandrake, soit a des tiers, soit attendre que les CDs soient dispos dans une revue.

              > Sinon pour ton idée de maintenir quelques paquets, je suis pas sûr qu'un gars qui n'a jamais tapé une ligne de C/C++ de sa vie

              Maintenir des paquets ne signifie pas coder pourtant. Contributeur ne signifie pas mainteneur ou codeur. Il s'agit d'utiliser rpm et d'ecrire un spec correct. Et pour ce faire, le wiki de cooker donne toutes les instructions.
              Par ailleurs, les paquets contrib ne sont pas acceptes aveuglement. Il y a des outils (comme rpmlint et autres) qui permettent de verifier que les dependances sont correctes, que le spec est correctement formate, etc... et le paquet n'est uploade que lorsqu'il passe les criteres. Bien sur parfois il y a des problemes. Mais bon quand c'est non-officiel...

              Au fait, je n'ai jamais dit que 2 rapport de bugs suffisaient pour devenir membre. Par contre maintenir un ou deux paquets dans contrib (de facon suivie et de qualite quand meme), oui. Un recensement de tous les contributeurs est fait avant chaque release d'ailleurs. Voila ;)
              • [^] # Re: Et chez Mandrake ils font quoi ?

                Posté par  . Évalué à 1.

                Hum, quand je parlais d'ADSL et de 56K, c'était au sens figuré : l'ADSL c'est le Club avec ses isos avant les autres, ses paquets de KDE en exclusivité (à vérifier sur ce point, je te l'accordes, mais on sera vite fixé sur ce point), etc., le 56K c'est les 3 isos de la download un mois après les autres, mais qui, là encore je te l'accordes, ont le mérite d'exister.

                Pour ce qui est de maintenir des paquets, il suffit de jeter un coup d'oeil à celui de K3B que j'ai voulu recompiler sur ma 10.1 depuis le .src.rpm de cooker, c'est de la belle ouvrage avec une bonne dizaine de patches dans tous les sens et un spec long comme une description de Balzac ! Et ça, moi, soyons modeste, je sais pas faire !

                Pour le reste, je tiens à préciser que j'aime vraiment bien Mandrake, que j'ai commencer à bidouiller dessus avec la 8.0, que j'ai réellement basculé avec la 9.1 (Powerpack, tiens, tiens !) mais que je suis un peu décu par leur dérive un peu trop commerciale à mon goût, c'est tout. Et si je lorgne du côté d'Ubuntu, je pense que je resterai encore un moment avec Mandrake, dont la qualité, à iso-configuration de Pc, s'est globalement bien améliorée.

                Putain, ça se voit que c'est la printemps, si ça continue je vais finir par rouler une galoche à Warly ! ;-)
        • [^] # Re: Et chez Mandrake ils font quoi ?

          Posté par  . Évalué à -7.

          Ouh là, ça moinsse à tout va par ici !


          Doit y avoir des gens de chez Mandrake :p
        • [^] # Re: Et chez Mandrake ils font quoi ?

          Posté par  . Évalué à 1.

          il y a des backports des principales nouveautes de KDE 3.4 dans le KDE 3.3.2 de Mandrake.

          Par exemple KPDF, amaroK, les patches dans KHTML, et pour x86 et x86-64, la limitation du scoping des symboles (demarrage + rapide).

          J'aime vraiment KDE, mais au lieu de conseiller SuSE sans arguments (autre que le numero de version), il aurait fallu qu'une personne test la version 64-bit de la Mandrake 10.2 (ou LE 2005) par rapport a la SuSE 9.2.

          Sinon il y a aussi la KLAX quii est pas mal, qui fonctionne mieux chez moi qu'une Ubuntu.
          • [^] # Re: Et chez Mandrake ils font quoi ?

            Posté par  . Évalué à 2.

            Par exemple KPDF, amaroK, les patches dans KHTML, et pour x86 et x86-64, la limitation du scoping des symboles (demarrage + rapide).

            Amarok ne fait pas partie des release KDE ( et ne le saura probablement jamais comme k3b ) .
  • # kpdf

    Posté par  . Évalué à 5.

    le nouveau kpdf est vraiment excelent
    notamment les deux nouvelles fonctionnalités :
    - possibilité de voir les pages en continues
    - possibilité de sélectionner du texte ou des images au choix
    • [^] # Re: kpdf

      Posté par  . Évalué à 10.

      Une autre grande fonctionnalité que beaucoup attendaient grâce à laquelle kpdf devient une application professionelle du niveau d'Acrobat Reader, et supporte pleinement la norme PDF : le support des limitations DRM.

      Malheureusement, il est désactivé par défaut, mais il suffit de faire :
      $ ./configure --enable-force-kpdf-drm
      et le tour est joué !

      Si ce n'est pas vous qui avez compilé, rien n'est perdu ! Vous pouvez demander à votre admin d'aller dans kiosk (l'outil d'administration de KDE pour restreindre la configurabilité du bureau lorsque c'est souhaitable).
      Il y a une option : skip_drm, valant malheureusement YES par défaut, ce qui a pour effet de laisser l'utilisateur configurer s'il veut respecter les DRM ou pas.
      Pas de panique ! Changez cette valeur pour NO et la propriété intellectuelle sera respectée.

      J'espère que les autres visualisateurs PDF supporteront cette feature présente depuis longtemps dans XPDF
      Cf : http://www.foolabs.com/xpdf/cracking.html(...)

      Je pense notemment à Evince pour gnome, ou au fork d'XPDF réalisé par freedesktop.
      • [^] # Re: kpdf

        Posté par  . Évalué à 3.

        Appeler la non possibilité de lire certains fichiers une "feature", c'est digne de la concurrence ça!

        Je ne vois pas ce que ça a à voir avec le respect de a propriété intellectuelle en fait
        • [^] # Re: kpdf

          Posté par  . Évalué à 5.

          bah, ça s'appelle de l'humour, mais il était 23h16 c'était déjà tard ;-)

          La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

          • [^] # Re: kpdf

            Posté par  . Évalué à 3.

            Oui, visiblement, c'était trop tard pour moi, et pour mon sens de l'humour. Toutes mes excuses à la Anonyme, agressé à tord par un mec trop grincheux :)

            Ça va mieux là...
      • [^] # Re: kpdf

        Posté par  . Évalué à 1.

        Une autre grande fonctionnalité que beaucoup attendaient grâce à laquelle kpdf devient une application professionelle du niveau d'Acrobat Reader, et supporte pleinement la norme PDF : le support des limitations DRM.

        Ça sert à quoi d'activer soit même une limitation des actions possible ?

        Je veux bien qu'Adobe le demande/éxige pour respecter pleinement la spec PDF mais quand même.

        Je trouve ridicule de forcer les utilisateurs à imprimer le document dans un fichier (ou faire une copie d'écran si l'impression est DRMisée) et à utiliser un logiciel de reconnaissance de caractère pour récupérer le texte.

        DRM = Digital Restriction Management
        • [^] # Re: kpdf

          Posté par  . Évalué à 6.

          Fais gaffe, ton détecteur d'ironie a l'air cassé.

          Blague à part, l' info à retenir, c'est que un contributeur de kpdf a cru bon d'implémenter les restrictions drm, et que le projet KDE n'a pas cédé au politiquement correct, et a promptement désactivé ça, ce qui est une bonne nouvelle je trouve.
  • # pourquoi virer autotools ?

    Posté par  . Évalué à 4.

    pourquoi ils ont l'intention de ne plus l'utiliser pour les prochaines versions ? c'est compliqué à maintenir ?
    les autotools permettent notamment de maintenir un environnement de production permettant de compiler aisément des sources pour plusieurs architectures différentes sans apporter de modif particulière à cet environnement
    chez debian, ils demandent avec insistance à ce que les programmes packagés utilisent autotools pour permettre de packager automatiquement pour plusieurs plateformes, donc si ils virent ça, ça risque de poser pb au moins sur debian (mais sans doute aussi ailleurs, quid de gentoo et autres ... ?)
    • [^] # Re: pourquoi virer autotools ?

      Posté par  (site web personnel) . Évalué à 0.

      Si ils virent autotools, c'est pour utiliser un truc mieux foutu et codé par un mec de Kde. Parce que bon, autotools...
      • [^] # Re: pourquoi virer autotools ?

        Posté par  . Évalué à 1.

        merci à toi et à Seb

        bon l'interet d'autotools c'est d'harmoniser cette tache entre les différents programmes
        je suis conscient que c'est pas parfait, mais plutot que de réinventer la roue à chaque fois qu'un truc ne va pas dans un logiciel (ça arrive souvent qu'il existe bcp de prog pour faire la même chose ... alors le choix c'est bien mais faut pas que ça empeche d'unir les forces en présence)
        je critique pas la (future) démarche de l'équipe kde (je me permettrais pas vu mon niveau), mais n'était-il pas possible/préférable de faire évoluer autotools plutot que de refaire un équivalent, ce qui va nuir à l'harmonisation dans ce domaine (et accessoirement emmerder debian)
        • [^] # Re: pourquoi virer autotools ?

          Posté par  . Évalué à 4.

          n'était-il pas possible/préférable de faire évoluer autotools
          Les autotools sont d'un complexité incroyable. C'et typiquement le genre d'outils qui semble avoir évolué de manière démeusuré et tentaculaire depuis trop longtemps. Le seul problème avec c'est que ça marche ;-).
          Parce que au final c'est chiant à utiliser mais ça permet de distribuer des sources qui vont pouvoir être compilés sur pleins de plateformes, ce qui est génial ! Mais c'est tellement énorme comme truc que le modifier pour en faire quelque chose de simple c'est pas réellement possible.
          Mais avoir un autre outils aussi puissant et plus élégant ne serait pas un mal.

          Pour faire un parallèle ça me rappele sendmail qui est lui même très puissant, mais complexe à configurer.
        • [^] # Re: pourquoi virer autotools ?

          Posté par  (site web personnel) . Évalué à 8.

          Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.

          Pour te repondre, je te redonne un bon dicton d'informaticien: "Il ne faut pas reinventer la roue. Sauf quand le premier inventeur a invente une roue carree".

          autotools, c'est clairement une roue carree. C'est un arrachage de cheveux a maintenir. Parmis les milliers de contributeurs et parmi la quarantaine de developpeurs principaux de KDE (qui ont un sacre niveau en informatique), il y a en tout et pour tout deux developpeurs qui comprennent completement le systeme des autotools utilise par KDE et qui sont capables de le maintenir. Ca ne fait pas beaucoup.

          Les developpeurs de KDE ne prennent pas des decisions techniques a la legere. Si ils se debarrassent d'autotools, c'est que ce n'etait plus gerable.

          Il y a des super projets pour remplacer autotools, qui ont tous la caracteristiques d'etre simple a utiliser et simple a faire evoluer. Deux qualite qui manquent terriblement a autotools. Je peux te dire que le type qui s'occupe d'autotools pour KDE (il me semble que c'est Stephan Kulow) est super motive pour utiliser autre chose, pour te donner une idee du truc.

          Scons semble etre une alternative interessante. Il y en a d'autres. Pourquoi se prendre la tete avec un systeme super complexe quand des alternatives plus simples existent.

          Faut pas etre trop sentimental. Autotools etait une bonne solution au moment ou il a ete cree, mais aujourd'hui, l'outil ne fait plus le poids. Avoir python ou perl installe sur sa machine n'est pas une contrainte extraordinaire alors qu'a l'epoque ou autotools a ete cree, sh etait la seule dependance acceptable.


          Par exemple, je suis toujours choque que ./configure ne detecte pas les erreurs de syntaxes dans ses options:

          ./configure --enable-truc-muche ne te renverra aucune erreur. Sauf que en fait, il fallait taper:
          ./configure --enable-trucmuche

          Et encore, ca c'est un probleme mineur d'utilisateur, rien a voir avec la complexite de la mise en place du truc.
          • [^] # Re: pourquoi virer autotools ?

            Posté par  . Évalué à 1.

            > Disons que vue la complexite d'autotools, je passe moins de temps a faire un support en live pour des config exotiques qu'a essayer de faire marcher ce bousin.
            > il me semble que c'est Stephan Kulow

            J'ai l'impression que les gens s'emballent pour rien. Si c'est pour unsermake, il ne remplace "que" automake.
            - "Unsermake is a replacement for automake by KDE developer Stephen Kulow."
            - "Unsermake replaces automake but keeps everything else, including the strange Makefile.am syntax the same."
            • [^] # Re: pourquoi virer autotools ?

              Posté par  . Évalué à 1.

              Oubliez ce commentaire, il semble que unsermake est déjà utilisé.
              • [^] # Re: pourquoi virer autotools ?

                Posté par  (site web personnel) . Évalué à 2.

                Oui, unsermake est deja utilise mais ton commentaire est tout a fait pertinent. unsermake ne fait que simplifier une des 12 etapes qui genere les makefile de KDE.

                Le but de se debarasser d'autotools, c'est probablement de passer de 12 etapes a 2, et de beneficier en sus d'ameliorations de performances diverses au niveau de la compilation.

                Je ne connais pas bien le sujet, mais j'ai entendu dire que le fait que make n'est qu'une vision repertoire par repertoire rend pas mal d'optimisations (distribution de la compilation, blocage de certains morceaux de la compilatino, ...) plutot difficiles.
                • [^] # Re: pourquoi virer autotools ?

                  Posté par  . Évalué à 2.

                  Moi personnellement, ca ne me gene pas que make ait une vision repertoire par repertoire. Tout ce qu'on attend de lui, c'est qu'il passe les bonnes options de compilation au compilateur pour le package qu'on est en train de compiler, et ensuite qu'il passe au package suivant, non ?

                  Ensuite, il me semble que la gestion de l'ordre de compilation des paquets, la possibilite de faire de la compilation parrallele (sur plusieurs machines et/ou sur plusieurs paquets) et autres optimisations doit etre efftectuee par une couche au-dessus : CMT, unsermake ou autre.
                  • [^] # Re: pourquoi virer autotools ?

                    Posté par  . Évalué à 3.

                    > Tout ce qu'on attend de lui, c'est qu'il passe les bonnes options de
                    > compilation au compilateur

                    en fait ce qu'un développeur attend de lui, c'est surtout qu'il ne recompile pas les 3/4 de ton arbre local au moindre changement si ce n'est pas strictement nécessaire.

                    Avec un make récursif, la gestion des dépendances inter-répertoires est lente et très aléatoire.
          • [^] # Re: pourquoi virer autotools ?

            Posté par  . Évalué à 2.

            Juste pour signaler un remplaçant très chouette et qui manque de publicité: pmk. http://pmk.sourceforge.net/(...)

            C'est un remplaçant entièrement en C pour autotools, libtool et pkg-config. C'est très éléguant, très rapide, très simple à utiliser, et ça diminue encore les dépendances et les problèmes liés au shell script (par rapport à autotools, ou python pour scons etc.).
            On peut supposer qu'il pourrai facilement être porté sur des plateforme win32 (plus que les shells scripts auto* pour sûr ;) même si ce n'est pas un objectif immediat.

            Je serai ravi que plus de developpeurs l'utilisent, en raison de l'objectif principal du projet: être irreprochable sur la sécurité pour l'utilisateur. Ça fonctionne sur la base de fichiers de description (parsés et 'éxecutés' par l'outil en C) avec bien entendu un nombre d'actions et de possibiltés prédéfinies et limités, bien étudiées. Il est censé ne pas permettre de faire des choses dangeureuses.

            En effet il ne faut pas oublier qu'un script configure est toujours susceptible de vous installer une rootkit en loucedé (ou jouer avec votre courriel ou ....). Les scripts configure (et libtool) sont très gros et complexes, en pratique très penibles à auditer ; comme c'est du shell script, tout leur est permis. Pensez-y quand vous installez à la main un nouveau logiciel ...
            • [^] # Re: pourquoi virer autotools ?

              Posté par  . Évalué à 2.

              Je veux pas jouer a celui qui a la plus grosse, hein, on n'est pas la pour ca :)
              mais CMT est ecrit en C++, deja porte sous win32 et solaris (pour solaris je m'avance un petit peu, j'en avais entendu parle, j'ai vu des bug reports, mais...), il me semble qu'il y a aussi possibilite de le scripter via python et une GUI (Visual CMT) est disponible.

              CMT lit lui aussi un fichier (habituellement appele requirements) dans lequel tu donnes les dependances aux paquets de ton appli, dans un langage relativement simple :
              use MonPaquet MonPaquet-00-00-01 Chemin/dans/larbo/rescence/de/mon/appli/vers/mon/paquet
              (sur une ligne)

              et puis tu lui dis ce que tu veux faire, un shared object, une appli static...
              La syntaxe est relativement simple (meme un physicien un peu bete comme moi peut s'en servir :)

              Ensuite c'est juste une affaire de configuration d'un (ou quelques) paquet mere dans lequel tu mets toutes les regles de compilations, les differentes actions que tu peux vouloir faire (creer la doc doxygen, lancer des scripts de pre/post-installation, configurer l'environnement de travail du developpeur (runtime, include paths,...), etc...)

              De plus CMT ce n'est pas *que* un programme pour compiler une appli, cela sert aussi a interagir avec ton appli (dans le sens demander quelles sont les dependances de tel paquet, ses clients,...)

              C'etait un message a caractere informatif.
      • [^] # Re: pourquoi virer autotools ?

        Posté par  . Évalué à 4.

        codé par un mec de Kde

        Un peu de respect quand même ;)
        Ce gars là c'est Stephan Kulow, release manager de KDE...
      • [^] # Re: pourquoi virer autotools ?

        Posté par  . Évalué à 1.

        Si ils virent autotools, c'est pour utiliser un truc mieux foutu et codé par un mec de Kde.

        En fait ils trouvent qu'autotools est trop rude à maintenir, et qu'il est trop dur d'y "renter". Mais a prioris ils vont peut etre utiliser unsermake (par un gars de kde) mais ca sera surement scons ou cmake
        • [^] # Re: pourquoi virer autotools ?

          Posté par  . Évalué à 6.

          Ils ont parlé aussi de la vitesse de compilation.
          En effet, il semblerait que rien qu'en filtrant l'affichage, on arrive à réduire la durée de compilation de quelques pourcents même sur un PC récent, parce que les console sont très très lentes !
          De plus, un configure qui prend 1 minute à tester 100 trucs ... c'est gonflant, surtout quand il le fait 15 fois !
    • [^] # Re: pourquoi virer autotools ?

      Posté par  . Évalué à 4.

      Je crois qu'ils veulent le(s) remplacer par un truc à eux : unsermake[1].

      Après une rapide lecture de la page, ce que j'en conclus c'est qu'ils veulent un peu plus rationaliser et factoriser le processus de compilation : regrouper les options de compilation dans un seul (gros?) Makefile.
      Moins de Makefile disséminés un peu partout dans l'arborescence.

      C'est quand même dommage de réinventer la roue avec unsermake : il y a déjà CMT[2] qui existe (quoi je ne vous ai pas encore parlé de CMT? Mais si regardez mes derniers journaux...) et qui est bien dimensionné pour les gros projets.

      [1] http://www.kde.me.uk/index.php?page=unsermake(...)
      [2] http://www.cmtsite.org(...)
      • [^] # Re: pourquoi virer autotools ?

        Posté par  . Évalué à 3.

        Unsermake a été créé suite à un article de Peter Miller[1] pointant les insuffisances de make et plaidant pour un procédé non récursif.

        Au début, c'était juste une expérience, mais les gains se sont avérés si substantiels que beaucoup de développeurs l'ont adopté au quotidien.

        [1] http://webcvs.kde.org/kdenonbeta/unsermake/doc/auug97.pdf?rev=1.1&view=auto
    • [^] # Re: pourquoi virer autotools ?

      Posté par  . Évalué à 4.

      donc si ils virent ça, ça risque de poser pb au moins sur debian

      Pas forcément. Ce qui emmerde le plus les développeurs c'est tout le bordel de macro M4 absolument imbitable. Pour les mainteneurs de paquets, l'important est de pouvoir modifier les options de compilation, notamment les chemins (--bindir=, --prefix) et activer/désactiver des composants optionels (--with-xxx, --without-xxx). Le packager se fout de savoir avec quoi le script configure a été généré du moment qu'il s'utilise de la même façon (./configure --plein-de-chose && make && make install). Il suffit de garder la même syntaxe pour les commandes et options et de remplacer les truc.in et machin.am par quelque chose de plus simple.
      • [^] # Re: pourquoi virer autotools ?

        Posté par  (site web personnel) . Évalué à 1.

        Les options nécessaires au packager :
        --enable-something (avec du --with ou autre tant que ça marche)
        --prefix (tout les prefix modifiables, pour mettre les fichiers de conf dans /etc ou autre selon le paquet, etc...)
        et une option pour installer le paquet dans un rep de destination sans se casser la tête a bouger 50 fichiers a la mais parce que le script marche pas...

        parce que honetement après le 50ème install --permission en tout genre tagada/src/machin.so RPM/DEB/ETC_ROOT_DIR/bonchemin(tm)/machin.so.bonneversion c'est super lourd!!!

        Perso j'aime bien les autotool et ça marche pas mal.
        Et si vous voullez pas vous casser la tête utilisez kdevelop pour créer votre projet avec, d'accord c'est lourd mais ilvous gère tout le bouzin très bien dans la plupart des cas sans se prendre la tête avec les dépendances en tout genre...
  • # Ubuntu

    Posté par  . Évalué à 7.

    Voilà juste pour préciser que chez Ubuntu ils packagent aussi KDE 3.4 et c'est disponible depuis aujourd'hui dans hoary :)

    Ubuntu décidemment c'est Bien (tm)
    • [^] # Re: Ubuntu

      Posté par  . Évalué à 4.

      Note pour éviter que d'autres se prennent la tête comme je viens de le faire, pour installer kde sous ubuntu:
      sudo apt-get install kubuntu-desktop
      c'est facile, mais faut le savoir.

      par defaut les polices ne sont pas anti-aliasées (bug), c'est juste une option à cocher dans kcontrol.
    • [^] # Re: Ubuntu

      Posté par  . Évalué à -1.

      Juste pour etre complet, ces paquets ont été faits à partir des paquets debian.

      (rendons à césar ce qui lui appartient)
  • # Vidéos

    Posté par  (site web personnel) . Évalué à 4.

    http://www.msu.edu/~ebyryan/vladi/(...)

    Deux ptites vidéos de présentation de KDE 3.4
    • [^] # Re: Vidéos

      Posté par  . Évalué à 1.

      C'est vrai que ca a l'air d'avoir du répondant ...
      pour ma part je suis plutot Gnome, mais il est vrai que sur la gestion de la transparence, et des outils de configuration KDE se debrouille vraiment pas mal ...
      dommage que le cycle de release soit totalement debianesque et que QT4 mette tant de temps a venir ... d'ailleur il est prévu pour quand et avec quelles améliorations en gros ?

      Appel à témoins :) .
      • [^] # Re: Vidéos

        Posté par  . Évalué à 2.

        Un cycle debianesque... T'es pas sous Debian hein :-) Six à neuf mois entre chaque release de Debian, ce serait une révolution ! C'est vrai que c'est "un peu" longuet, mais ça reste très raisonnable.

        Qt 4 est prévu en finale pour juin je crois. Donc le temps de tout porter vers le 4, on aura "en théorie" une 3.5 pour une date indéterminée vers la fin de l'année et un KDE 4 dans le courant de l'année suivante.
  • # Férus de screenshots

    Posté par  . Évalué à 2.

    Je remarque que ce sont toujours les liens donnant sur les impressions écran qui ont le plus de succès :)
  • # Autre petits plus

    Posté par  (site web personnel) . Évalué à 1.

    * KMail KMail now stores passwords securely with KWallet
    * SVG files can now be used as wallpapers

    C'est vachement sympa ça ! C'est le premier gestionnaire de fenêtres qui supporte les fonds d'écran vectoriels, ou bien ?

    Haypo
  • # Grande nouvelle pour les Gentooistes

    Posté par  . Évalué à 3.

    Comme je l'avais dit précédemment, KDE 3.4 marque un tournant pour KDE sur Gentoo, c'est la première version à séparer les applications.
    Voir : http://gentoo-portage.com/kde-base(...) pour s'en convaincre, au lieu des trois ou quatres gros paquets monolithiques, on dispose de plusieurs paquets, un par application.

    Note : pour KDE < 4.0, l'ancien système avec les paquets monolithiques restera.

    Un petit lien utile, traduit par votre serviteur :
    http://www.gentoo.org/doc/fr/kde-split-ebuilds.xml(...)
    Qui explique le pourquoi du comment.

    Faites chauffer votre Portage :)

Suivre le flux des commentaires

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