Sortie de la Mandriva Linux 2008.1 Spring

Posté par (page perso) . Modéré par Amaury.
Tags :
0
10
avr.
2008
Mandriva
La nouvelle Mandriva Linux vient de sortir ! Comme au précédent printemps, elle est estampillée « Spring » (alias 2008.1). Après de nombreuses semaines de tests (alpha, bêta, RC), la voici donc disponible à tous, sous toutes les versions (i586 ou x86_64).

Au menu de cette nouvelle mouture, on peut citer le prise en charge complète de l'Asus EEE PC, la possibilité de synchroniser les logiciels d'agenda avec la plupart des PDA (incluant Windows Mobile 5 et supérieur, ainsi que les Blackberry et les téléphones Nokia). Elle inclut également un gestionnaire de codecs pour les applications multimédias (Codeina). KDE y est en version 3.5.9 et la version 4.0.3 est disponible sur les miroirs officiels. GNOME quant à lui est en version 2.22. Enfin, on y retrouvera également OpenOffice.org en version 2.4, le noyau Linux 2.6.24.4, X.org 7.3, Compiz 0.7, et bien d'autres !

Si l'installation vous fait peur, la version One (sur un live-CD) est également disponible (une version spéciale KDE ou une version GNOME, au choix, sont disponibles). L'installation des outils de synchronisation pour les PDA se fait grâce aux méta-paquets task- installant les logiciels préférés pour GNOME ou KDE et notamment le framework OpenSync permettant la synchronisation par SyncML :
Une installation simplifiée des différents types de serveur LAMP est aussi disponible via les méta-paquets task-lamp:
  • task-lamp-perl
  • task-lamp-php
  • task-lamp-python
Un sondage entre x86_64 et i586 vous permettra de sélectionner ce qui vous convient le mieux, le x86_64 étant un bon détecteur de logiciels non libres.

Pour le téléchargement, afin d'éviter d'écrouler plus les serveurs FTP, vous pouvez utiliser bittorrent (sélectionnez la version qui vous convient, contenant Spring bien sûr).

La documentation de prise en main de Mandriva Linux est disponible dans les paquets mandriva-doc et aussi directement téléchargeable au format PDF ; le wiki est à la disposition de tous sous licence libre CC-by-sa et documente par exemple le centre de contrôle Mandriva Linux (aka MCC ou CCM) qui permet de disposer d'assistants pour une configuration facilitée et avancée de votre système.

Enfin, pensez à prendre 5 minutes pour signaler votre configuration sur Hardware4Linux en installant hwreport (inclus sur les dépôts), cela servira à d'autres pour sélectionner du matériel qui fonctionne ; via le centre de contrôle vous pouvez aussi directement soumettre les données dans la liste de compatibilité matérielle de Mandriva.
  • # UPNP & Coherence

    Posté par . Évalué à 10.

    On notera aussi l'intégration de Coherence qui permet de partager simplement les données de vos dossiers XDG (Images/Photos/Videos) via UPNP. Ainsi, il est possible par exemple, d'acceder au contenu multimedia de son ordinateur personnel depuis une PS3, une XBOX 360, un nokia n810 ou une TV possédant un client UPNP.

    On peut également utilisé elisa comme client sur une autre machine linux ce qui permet de partager simplement musique, video, photos entre 2 machines Linux.
    • [^] # Re: UPNP & Coherence

      Posté par . Évalué à 3.

      Une petite question...

      Pour ma part j'utilise mediatomb comme serveur uPnP. Il a une interface web pour ajouter/enlever le contenu après une config de base avec un bon vieil éditeur.

      Pour coherence, que je n'ai jamais testé, il y a t il également une interface qui le fait fonctionner une fois le rpm installé ou faut il quand même mettre le nez dans les fichiers de conf ?

      Sinon, pour utiliser cette version de Mandriva en cooker 64 bits, c'est vraiment une très bonne release je trouve.
      • [^] # Re: UPNP & Coherence

        Posté par . Évalué à 6.

        Coherence est packagé en deux parties. python-coherence qui est le programme principal avec fichier de conf et cie : c'est le mode "traditionnel".

        Tu as ensuite la possibilité d'utiliser une applet python-coherence-applet qui a été développée par un contributeur Mandriva (merci neoclust) et intégrée upstream dans cette version 0.5.4.

        Une fois que l'applet est installée, tu peux l'ajouter dans ta zone de notification (via le menu internet/coherence)

        Après, depuis l'applet, tu peux démarrer/stopper coherence qui fonctionne alors sans aucune configuration ! C'est vraiement pratique. Il va partager automatiquement tes répertoires XDG aka photos/video/musique.

        Bref, l'applet te permet d'avoir un partage UPNP sans aucune configuration ni base de données etc... Un vrai progrès pour l'utilisateur.
        • [^] # Re: UPNP & Coherence

          Posté par . Évalué à 3.

          Hum, c'est pas mal, je vais tester ça ce soir.
          Par contre, je me pose de fait une autre question...
          Quand tu dis répertoires XDG, tu parles de ce concept http://standards.freedesktop.org/basedir-spec/basedir-spec-0(...) ?
          Si j'ai bien compris, les dossiers sont donc définis préalablement dans une variable d'environnement standard et coherence sait s'en servir pour trouver les fichiers à partager.
          Si j'ai tout faux : comment sont définis ces répertoires XDG ?
          • [^] # Re: UPNP & Coherence

            Posté par . Évalué à 1.

            Tu as tout bon ;o) Tu trouveras la liste des reps XDG dans ~/.config/user-dirs.dirs
            Normalement, tout ça c'est déjà bien configurer.
            N'hesites pas faire des retours sur ton expérience, et viens sur #mandrivafr (sur freenode) si tu veux en discuter.
    • [^] # Re: UPNP & Coherence

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

      > depuis une PS3, une XBOX 360, un nokia n810 ou une TV possédant un client UPNP.

      ou bien même GeeXboX ...
  • # dommage

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

    Dommage que Mandriva s'obstine à utiliser les rpm de RedHat. Ça lui coute cher finalement d'avoir tout pompé sur la mauvaise distribution pour finir par utiliser un horrible gestionnaire de packets franchement limité.

    Dommage aussi qu'il faille payer pour disposer de la version complète et des forums.

    Dommage enfin qu'elle soient si laide et mal configuré et que les outils de configuration, qui sont propriétaires, soient aussi instables et envahissants.

    De toute façon, c'est la plus mauvaise distrib que je connaisse. La dernière fois que j'ai essayé de l'installer, elle m'a grillé 2 disques dur et un lecteur DVD. Sans compter que j'ai chopé un lumbago.

    Les dev feraient bien de se remettre au travail et de s'inspirer d'une vraie distrib comme Ubuntu !
    • [^] # Re: dommage

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

      C'est tellement un ramassie de conneries ton post que j'ai même pas envie de la moinser
      • [^] # Re: dommage

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

        à mon avis c'est ironique, c'est beaucoup trop gros.
        • [^] # Re: dommage

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

          Ça sert à quoi que je me décarcasse si tu me casse la baraque ?
          • [^] # Re: dommage

            Posté par . Évalué à 7.

            tu aurais pu être un peu plus fin quand même.
            • [^] # Re: dommage

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

              J'ai du faire vite. Un troll comme ça, faut que ça soit dans les tout premier commentaire, sinon c'est mort.

              Et il ne se porte pas si mal que ça tout de même.
              • [^] # Re: dommage

                Posté par . Évalué à 4.

                Là je dis: félicitations! Parce que, même en annonçant la couleur et en criant au troll à tue-tête, ça marche quand-même à tout berzingue... Au final, il ne t'a même pas cassé ton coup!

                Respects :-) .
      • [^] # Re: dommage

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

        >C'est tellement un ramassie de conneries ton post que j'ai même pas envie de la moinser

        Si tu avançais des arguments de critiques gratuites ?
    • [^] # Re: dommage

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

      Hé!
      On avait pas dit qu'on trollait sur le journal de sa sortie, et qu'on gardait les commentaires pertinents sur la dépêche?
      Surtout qu'on n'est pas vendredi!
      Du coup je sais plus où poster, moi!
      • [^] # Re: dommage

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

        >On avait pas dit qu'on trollait sur le journal de sa sortie, et qu'on gardait les commentaires pertinents sur la dépêche?

        Ben oui :-)
    • [^] # C'est pour la télé ?

      Posté par . Évalué à 0.

      Je suppose que c'est une tentative d'obtenir la note la plus basse possible :-)
    • [^] # Re: dommage

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

      Je me doute que ça sent le troll mais je ne peux pas m'empêcher de répondre parce que si on ne répond pas (ou juste en disant que c'est un troll) au final ça ne vaut pas vraiment le coup et le lecteur reste sur les idées qu'il a lues.

      La gestion des rpm à travers rpmdrake est largement satisfaisante pour moi. Rpmdrake n'a cessé de progresser depuis plusieurs versions aussi bien en ergonomie qu'en rapidité. Quant au débat entre .deb et .rpm je dois avouer ma totale incompétence d'une part n'étant pas développeur et d'autre part n'utilisant pas de distribution à base de .deb pour pouvoir comparer objectivement sur la facilité d'emploi.

      Le forum officiel est totalement gratuit depuis pas mal de temps, l'inscription est gratuite et tout le monde peut intervenir librement, y compris pour critiquer Mandriva, la distribution, la société.

      Les outils de configuration sont sous licence GPL, stable de mon point de vue et utilisable aussi bien avec que sans interface graphique (ce qui est très pratique pour remettre d'aplomb la configuration du serveur X avec XFdrake sans avoir besoin de bidouiller un fichier de configuration dans la console). L'aspect visuel est du goût de chacun, certains apprécient le bleu, d'autres le vert ou le marron.

      Elle mérite le coup d'œil et de mon point de vue elle rend l'utilisation de Linux très facile et permet de se passer de toute ligne de commande pour se faire oublier et se consacrer à l'utilisation de son ordinateur et non à la maintenance de son système d'exploitation.

      Maintenant on peut débattre ou troller sur des bases sérieuses ;)
      • [^] # Re: dommage

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

        On sait que le débat rpm/deb est un débat stérile (du point de vue du Jean-Kevin, j'entends) sauf dans l'étude approfondie des choses, et là on se rend compte que les deux format sont côte à côte, à quelques fonctionnalités poussées près... C'est un peu comme comparer des perfo bosh et b&d.
        Mais et le lumbago ? hein ? hein ?
        Il n'est toujours pas prouvé que mandriva n'est pas responsable des lumbagos ;)
        • [^] # Re: dommage

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

          Non je t'assure, Bosch c'est beaucoup plus mieux de Black & Decker puisque je le dis :-)
          • [^] # Re: dommage

            Posté par . Évalué à 6.

            Pas du tout, efface ! Il vaut mieux l'avoir Black & Decker que blanche et molle.
    • [^] # Re: dommage

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

      Ça lui coute cher finalement d'avoir tout pompé sur la mauvaise distribution pour finir par utiliser un horrible gestionnaire de packets franchement limité.

      Je ne suis pas non plus un adepte du gestionnaire de paquets RPM, lui préférant APT que je trouve plus souple et plus pratique. Mais loin de moi l'idée de lancer le débat.

      Je profite de ce point pour m'informer su le projet Autopackage http://autopackage.org.
      Qu'en est il de son intégration dans les différentes distributions ? et surtout de son usage chez les différents mainteneurs de paquet ... ?
      Certaines personnes auraient de l'info ? Je sais que ce n'est pas vraiment le lieu m'enfin, vous pourriez m'accorder quelques liens et avis ... :D

      Alexandre COLLIGNON

      • [^] # Re: dommage

        Posté par . Évalué à 9.

        > Je ne suis pas non plus un adepte du gestionnaire de paquets RPM, lui préférant APT que je trouve plus souple et plus pratique

        Déjà première erreur, l'équivalent de RPM ce n'est pas APT mais dpkg.
        RPM et dpkg sont des système de gestion de paquets, yum/urpmi et apt-get/aptitude sont des systèmes avancés de gestion de paquets qui se basent respectivement sur les systèmes précédemment cités.

        Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
        Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.
        • [^] # Re: dommage

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

          Déjà première erreur, l'équivalent de RPM ce n'est pas APT mais dpkg.

          Merci pour la correction, c'est une erreur grossière.

          Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)

          Je ne vais pas donner mon avis ici, on va dire que je troll. :D

          Alexandre COLLIGNON

        • [^] # Re: dommage

          Posté par . Évalué à 1.

          > yum/urpmi et apt-get/aptitude sont des systèmes avancés de gestion de paquets

          Mouaif...
          rpm/apt est bas-niveau. Ils connaissent le format des paquets (à quel offset est stocké telle ou telle information, etc), il fait tous les contrôles en toute fin, il lance les scripts d'installations, contrôle les conflits entre fichiers, c'est rpm qui fait la vérification de signature, etc.
          Il y a largement plus de code pour rpm que pour yum.
          Yum (ou autre) est "seulement" un utilisateur de rpm (ou librpm). Il n'est pas plus avancé que rpm. Il fait des choses que ne fait pas rpm. Des choses qui ne sont pas nécessaire pour l'outil de bas niveau. Par exemple downloader les paquets, ajouter automatiquement un paquet s'il y a une dépendance, etc.

          En passant, rpm avait la gestion automatique de dépendance. Ça utilisait rpmdb (qui n'est plus fournit). La fonctionnalité, si elle existe encore, n'est pas supportée.
        • [^] # Re: dommage

          Posté par . Évalué à 2.

          Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)

          tu aurais du mettre cela dans le journal spécial troll
          • [^] # Re: dommage

            Posté par . Évalué à 7.

            > tu aurais du mettre cela dans le journal spécial troll

            A part la réputation de deb, il y a quoi de formidable dans deb ?
            Deb vient d'avoir les trigger alors que ça existe depuis des lustres sous rpm. En passant, c'est spécifique Ubuntu. Rpm supporte les systèmes bi-arch (i386/x86_64). Rpm a la signature (GPG) des paquets depuis des lustes alors que dpkg depuis quelques mois.

            Il y a un truc qu'a deb et non rpm, c'est les suggestions.

            > tu aurais du mettre cela dans le journal spécial troll

            Fait un journal qui démontre la supériorité de deb sur rpm.
            Fait de même pour apt et yum si tu veux.
            • [^] # Re: dommage

              Posté par . Évalué à 3.

              Je pense que ce que Stephane veut dire, c'est que les problemes de dependances avec rpm ne sont pas "revolus" (si tant est que le terme de "revolu" a une connotation de "recemment resolu") mais qu'ils n'existent plus depuis belle lurette. Je me souviens avoir utilise urpmi des 1998, et qu'il remplissait deja bien une fonction equivalente a apt (en telechargeant et installant les dependances a partir des listes sur les depots de paquets).
              • [^] # Re: dommage

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

                Cette incompréhension chronique de ce qu'est RPM est quelque peu exaspérante. Il faut comprendre que :

                - rpm gère les paquets, mais pas leurs dépendances.
                - urpmi est une surcouche à rpm qui gère les dépendances.
                - rpmdrake est une surcouche graphique à urpmi

                Ce schéma est volontairement simplifié. Le comprendre devrait permettre d'éviter de dire des bêtises.

                Il y a aussi l'applet "Mandrake On line" qui 'appuie sur urpmi et permet de mettre la distribution à jour d'un seul clic !
                En ligne de commande urpmi.update -a && urpmi --auto-select fait la même chose.

                La gestion de paquets de Mandriva n'a rien à envier aux autres distributions, bien au contraire !
                • [^] # Re: dommage

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

                  "urpmi --auto-update" remplace "urpmi.update -a && urpmi --auto-select"

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

                • [^] # Re: dommage

                  Posté par . Évalué à 5.

                  > - rpm gère les paquets, mais pas leurs dépendances.

                  rpm gère les dépendances !
                  Ce que ne fait pas rpm, c'est les résoudre automatiquement.
            • [^] # Re: dommage

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

              C'est juste debian qui a inventé les .deb, alors vu que debian caybien, trucbuntu caymieux et mandriva caca.
              Faut pas chercher loin
            • [^] # Re: dommage

              Posté par . Évalué à 6.

              Il y a un truc qu'a deb et non rpm, c'est les suggestions.

              Faux, rpm gère les suggestions : Suggests: dans les fichiers spec
              • [^] # Re: dommage

                Posté par . Évalué à 3.

                T'es sûr ?
                Car je crois que Jeff Johnson avait proposé ça assez tard (année 2007) et que rpm (rpm.org) l'a refusé. Par contre rpm de Jeff Johnson (rpm5.org) l'a peut-être.

                Il me semble que conectiva était contre et Fedora est contre aussi. En passant, Fedora a les groupes (fichier comps.xml) depuis des lustes. Ce qui limite l'intérêt des suggestions.
                Les groupes sont gérés par yum (et ses fils graphiques).

                Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
                Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.
                • [^] # Re: dommage

                  Posté par . Évalué à 7.

                  Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
                  J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.

                  Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
                  Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.


                  Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
                • [^] # Re: dommage

                  Posté par . Évalué à 1.

                  Certain, c'est utilisé par urpmi depuis la 2007.0 ou 2007.1 je crois, en tout cas je l'ai utilisé dans des paquets depuis la 2008.0.
                  J'ai jeté un coup d'oeil, et à priori c'est implémenté dans rpm depuis 2005.

                  Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
                  Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.


                  Bah si c'est leur position, je trouve ça ridicule, s'il ne veulent pas d'un Suggest: xxxx, ils n'ont qu'à pas le mettre dans leur spec. A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances, certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.
                  • [^] # Re: dommage

                    Posté par . Évalué à 1.

                    > A ce moment là il faudrait qu'ils suppriment complètement la gestion des dépendances

                    Ne soit pas débile.

                    > certaines distributions pourraient avoir la politique de définir un Requires: adobe-flash pour reprendre ton exemple.

                    Es-ce que Firefox nécessite adobe-flash ?
                    Non.
                    Chaqu'un est libre de violer rpm. Des cons il y en aura toujours.
                • [^] # Re: dommage

                  Posté par . Évalué à 3.


                  Ce qui se disait chez Fedora, est que les suggests, etc n'avaient pas à être dans le gestionnaire de paquet car ça dépend de la politique de la distribution.
                  Par exemple une distribution pourrait mettre "suggest : adobe-flash" pour Firefox et d'autres se le refuser.

                  Et alors je ne vois pas le problème, si mandriva dans son paquet firefox veut y inclure une dépendance molle vers flash, je ne vois pas en quoi ça impacte Suse/Fedora/... Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.
                  • [^] # Re: dommage

                    Posté par . Évalué à 2.

                    Rpm répond à un problème technique.
                    Il n'est pas politique.

                    > Qui, autant que je le sache font leurs propres fichier spec et donc y mettent ce qu'ils veulent.

                    Oui. Mais un rpm n'est pas forcément fait pour et par une distribution. Certains rpms (lsb compatible) peuvent être installer partout.
                    Et si je veux l'installer, je ne veux pas qu'il me sugère flash d'adobe. Le boulot de rpm, c'est (entre autre) l'installation des programmes. Pas un truc pour faire de la pub à flash d'adobe.
                    • [^] # Re: dommage

                      Posté par . Évalué à 1.

                      Et pourquoi pas un noyau qui suggère le driver proprio de NVidia s'il détecte une carte NVidia...

                      L'horreur...
                      • [^] # Re: dommage

                        Posté par . Évalué à 2.

                        Aucun rapport avec rpm, a moins que le script d'install d'un rpm puisse modifier à la volée les dépendances du rpm dont il fait partie, fonctionnalité potentiellement intéressante mais non implémentée autant que je le sache
                        • [^] # Re: dommage

                          Posté par . Évalué à 1.

                          > a moins que le script d'install d'un rpm puisse modifier à la volée les dépendances du rpm dont il fait partie, fonctionnalité potentiellement intéressante mais non implémentée autant que je le sache

                          Je ne vois pas le rapport.
                          • [^] # Re: dommage

                            Posté par . Évalué à 2.

                            Je ne vois pas d'autre moyen pour que le rpm d'install du noyau te suggère le module nvidia si tu as une CG nvidia (ou alors il faut que tu m'explique comment tu fais ta détection de CG)
                            • [^] # Re: dommage

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

                              Je vois bcp d'autres moyens de faire çà a un autre niveau. Le niveau idéal est le meta gestionnaire de paquet non pas la couche bas niveau dont le boulot doit être réduit à son minimum, à savoir packager un logiciel sans autre forme de fioritures.

                              Small is beautiful, guys.

                              Le graphe de dépendances et de suggestions ne doit pas être gérer au niveau du logiciel de paquet, c'est de l'over engineering d'un logiciel çà.

                              a +.
                            • [^] # Re: dommage

                              Posté par . Évalué à 1.

                              OK.
                              Au chargement du module nv, il pourrait y avoir un message dans /var/log/message qui suggère le driver proprio.
                              Je suis contre ce principe.

                              Après du pourrait avoir Firefox qui suggère Gnome s'il ne trouve pas Gnome, etc.
                              C'est la (mauvaise) idée globale qu'il faut voir ici. Pas le côté technique.
                              • [^] # Re: dommage

                                Posté par . Évalué à 4.

                                enfin là t'es carrément sorti du cadre d'un gestionnaire de paquetage non ?

                                Pour tu donner un contre exemple, je te donnerai l'exemple du paquet task-kde sous la mandriva (2008.1 précisement)

                                si je veux installer le task-kde celui-ci me tire via un jeu de dépendance dures :
                                Kerry -> Beagle -> Mono -> ...

                                super !!!! Je voulais KDE et je me retrouve avec ce gros bloatware de mono. Alors qu'il aurait juste fallu avoir mis Kerry en suggest et hop ! Je peux garder mon task-kde (qui me facilite l'install de kde) sans avoir (trop) de cochonneries (Brevets / techno microsoft / MDI) d'installées sur ma machine
                                • [^] # Re: dommage

                                  Posté par . Évalué à 2.

                                  Avec les groupes dans un fichier xml comme dans un Fedora, tu as un système similaire. Dans un groupe, tu as les paquets essentiels et les paquets supplémentaires (ou suggérés).
                                  L'avantage est que c'est plus souple à maintenir, je ne change qu'un fichier xml et non pas un fichier spec qui signifie recompilation du paquet, mise à jour inutile pour 99% des utilisateurs etc ..., si tu dois faire ça assez souvent, ça devient vite lourdingue. Les concepteurs de RPM ont fait choix, celui de laisser la gestion des groupes à l'outil de haut niveau.
                                  Si tu veux un mécanisme de suggestions, il faut l'implémenter dans urpmi et non pas dans RPM.
                                  • [^] # Re: dommage

                                    Posté par . Évalué à 2.

                                    Oui enfin tes suggests, tu les changes pas tous les 4 matins non plus, Une fois ta distrib sortie en version N, tu t'amuses pas à les changer (quelque soit sa manière d'être implémentée). Et les scripts de reconstruction nocturnes sont utilisés par à peu près toutes les distrib, donc c'est un faux probleme
                                    • [^] # Re: dommage

                                      Posté par . Évalué à 3.

                                      > donc c'est un faux probleme

                                      Ce n'est pas un faux problème.
                                      Pour Fedora il y a :
                                      - Fedora (full, avec evolution par défaut, etc)
                                      - Fedora KDE (avec kmail par défaut, etc)
                                      - Fedora Games
                                      - Fedora Developers
                                      - Fedora Electronic Lab
                                      - Fedora XFCE

                                      Il y a en peut-être d'autres. Toutes ses distributions utilisent les mêmes paquets rpm. On n'a pas à recompiler 6 (!) fois le même paquets. Gain de temps et d'espace disque (ose imaginer le cas de OOo).

                                      > donc c'est un faux probleme

                                      La place disque (sur les mirroirs) commence a être un sérieux problème.
                                      • [^] # Re: dommage

                                        Posté par . Évalué à 2.

                                        Tout cela peut se gérer très facilement via un jeu de sources de paquets ( un peu à la manière d'ubuntu / kubuntu / ... ) qui partagent la même base et quelques meta paquetages (que tu n'aimes pas mais que que beaucoup de distrib utilisent, donc ce ne peut pas être entièrement mauvais).
                                        Ton OOo il est dans un repository commun a toutes tes versions de Fedora, et eventuellement dans ton Fedora KDE tu y colles un paquet qui permet de KDEiser son interface pour qu'elle s'integre mieux dans KDE.
                                        • [^] # Re: dommage

                                          Posté par . Évalué à 2.

                                          Admettons. En passant, je crois que tu mélanges avec un autre problème.

                                          Mais vois comme cette "mauvaise" idée a rapidement des répercutions.
                                          Es-ce que rpm doit encourager ce type de truc ?
                                          Je ne crois pas.
                                          Ceci dit, je pense avoir bien compris ton avis et que tu as bien compris le mien.
                                          Donc j'arrête.
                                  • [^] # Re: dommage

                                    Posté par . Évalué à 3.

                                    J'ajoute pour être clair, je ne suis pas contre le principe de suggérer ou des meta-paquets. Mais ça ne doit pas (à mon avis) être fait au niveau de rpm.

                                    On peut voir que yum c'est étoffé avec des informations qui n'ont pas leur place dans rpm. Par exemple des informations qui indiquent si le paquet est un correctif de sécurité (pertinant pour une mise à jour, mais sans intérêt pour une nouvelle release). Cette informations est par rapport à l'ancien paquet et donc implique un "workflow" dont rpm est totalement étrangé. Donc cette information, aussi utile soit-elle, n'a pas à être dans rpm.

                                    Ce n'est pas car une information est utile, qu'il faut la foutre n'importe où.
                                • [^] # Re: dommage

                                  Posté par . Évalué à 1.

                                  Ben cette pratique des meta-paquets n'est pas bonne à mon avis.
                                  Je dis ça, c'est une news Mandriva, je vais me faire exploser et accuser d'insulter les développeurs, de chier sur ... etc...
                                  Bref, je n'irais pas plus loins sauf pour dire qu'il y a des alternatives à ces meta-paquets.
                                • [^] # Re: dommage

                                  Posté par . Évalué à 2.

                                  dommage, on ne peux plusser qu' une fois
                                  gnome / f-spot / mono > /dev/null
                    • [^] # Re: dommage

                      Posté par . Évalué à 2.

                      Je ne vois pas en quoi mettre en suggest (qui est une dépendance molle, donc optionnelle) dans un fichier spec est politique.
                      Tu prends le mauvais exemple d'une dépendance vers un lib proprio, alors qu'il pourrait y avoir des dizaines d'exemple concernant du pur libre (entre autres dans le multimedia).
                      Un package est toujours créé pour une version de distribution a cause des dépendances dures concernant des versions de bibliothèques par exemple, donc le fichier SPEC n'est pas écrit pour lsb mais pour une version précise de distribution, tout en tenant compte des recommandations lsb qui portent surtout sur des emplacements de fichier autant que je le sache.

                      Si le paquet rpm de mandriva qui tu voulais installer sur ta fedora te fais des suggestions qui te de plaisent, tu peux toujours :

                      - prendre un autre paquet : Suse / CentOS / ... en proposent ( Fedora aussi ;-) )
                      - refaire le paquet en virant le suggest a partir du src.rpm
                      - ignorer le suggest

                      Je trouve que c'est un choix plus que raisonnable.
                      • [^] # Re: dommage

                        Posté par . Évalué à 1.

                        Je ne suis pas contre les "dépendances molles" ou les suggestions.
                        Je dis seulement que ça ne doit pas être fait au niveau de rpm (qui est le plus bas niveau).
                        Fedora a des "dépendances molles", c'est traitée avec le fichier comps.xml. C'est dans ce fichier qu'on trouvera les décisions "politiques". Pas au plus bas niveau.
                        Le fichier comps.xml est au niveau de la distribution (et techniquement rien n'empêche de l'utiliser avec des .deb ou autre).
                        Au plus bas niveau on doit avoir le minimum de dépendance et ne pas faire de suggestion. Ça améliore la réutilisation.

                        > donc le fichier SPEC n'est pas écrit pour lsb

                        Ben parfois oui. Parfois il est fait pour plusieurs distributions.
                        Un exemple récent :
                        http://developer.amazonwebservices.com/connect/entry.jspa?ex(...)
                        Ce n'est pas fait spécifiquement pour une distribution.

                        Et après, que fais tu des suggestions ?
                        Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.
                        • [^] # Re: dommage

                          Posté par . Évalué à 2.


                          Et après, que fais tu des suggestions ?

                          Simple, si elle ne sont pas disponibles, tu ne le propose même pas.
                          Sinon tu propose (après entre le opt-in et le opt-out ça c'est effectivement purement politique)

                          Le problème du comps.xml (que je ne connais pas vraiment) c'est que c'est géré au niveau de yum non ? Dans ce cas quid des autres distrib qui n'utilisent pas yum ? Elle est où la compatibilité inter distribution ?
                          • [^] # Re: dommage

                            Posté par . Évalué à 1.

                            > Elle est où la compatibilité inter distribution ?

                            Elle n'existe pas, c'est quasi intentionnel.
                            Ainsi tu peux avoir une distribution avec le bureau par Gnome défaut, une autre avec KDE, une autre avec evolution par défaut, une autre avec thunderbird, une autre qui installe tout Gnome et une autre qui installe que le minimum pour Gnome, etc.
                            comps.xml est spécifique à la distribution.
                            Par contre rpm ne l'est pas.
                            Les suggestions sont spécifiques à une distribution (à sa politique/philosophie), donc ils ne devraient pas être au niveau de rpm. Rpm s'occupe que de questions techniques.
                            • [^] # Re: dommage

                              Posté par . Évalué à 2.

                              rpm n'est pas spécifique à une distribution mais les fichiers spec le sont.
                              Je te rappelle que je ne plaide pour avoir l'obligation mais la possiblité d'utiliser le suggest, c'est tout à fait optionnel.
                              Libre après à chaque mainteneur de paquetage/distribution de l'utiliser selon ses goûts et ses envies.
                              Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm, c'est sa présence ou non et les dépendances qui s'y trouvent (autrement dit la manière de l'utiliser) qui est propre à une distribution.
                              • [^] # Re: dommage

                                Posté par . Évalué à 1.

                                > Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm

                                C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.
                                Après tu peux ajouter les résolutions automatiques (et optionnels) des dépendances, le choix du mirroir à utiliser (optionnel), l'interface graphique (optionnelle), etc.
                                Ce principe moux va à la catastrophe ou du moins est la voix royale au n'importe quoi.
                                Après le suggest, il y aura le suggested-doc (ça ne fait pas de mal, c'est optionnel), le suggested-skin (ça ne fait pas de mal, c'est optionnel), le suggested-ram (ça ne fait pas de mal, c'est optionnel), etc.

                                Ceci sucks dans les grandes largeurs.

                                Tu aimes ça, je n'aime pas ça, on ne sera pas d'accord.

                                > Le "suggest" est une possiblité technique donc a tout à fait sa place dans rpm

                                Ben il n'y est pas.
                                Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).
                                • [^] # Re: dommage

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

                                  > C'est comme les options en tout genre dans un bureau. C'est optionnel, mais ce n'est pas le lieu si on veut en faire un bureau pour beaucoup.

                                  Mais non justement ça n'a rien à voir.
                                  D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute), gnome a des options.
                                  Seulement elles ne sont pas toutes visibles et pour certaines on ne peu y accéder que par gconf.
                                  Mais les options sont là.

                                  Ben là c'est pareil, rpm gère les requires, devrait gérer à mon sens les suggest (qui ne sont qu'une forme de dépendance, optionnel mais dépendance)
                                  Et comme actuellement, c'est aux sur couches (urpmi, yum, ...) d'installer, proposer, etc, tenir compte de suggest ou non. Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.

                                  Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...
                                  Finalement je crois que je comprend pourquoi il y a un fork de rpm...
                                  • [^] # Re: dommage

                                    Posté par . Évalué à 2.

                                    > D'ailleurs pour prendre gnome en exemple (puisque c'est ce que penses je me doute)

                                    Bien vu.
                                    Mais c'était une connerie de ma part.
                                    Rpm a des objectifs (que) technique. Ce n'est pas le cas de Gnome.

                                    > une forme de dépendance, optionnel mais dépendance

                                    Une dépendance optionnelle n'est pas une dépendance.
                                    Quand penses-tu ?

                                    > Comme c'est fait actuellement si on a plusieurs paquets ayant le même provides par ex.

                                    Je ne peux pas parler pour Mandriva, mais pour Fedora ce n'est pas fait comme ça.
                                    J'ai Gnome comme bureau, je peux (et d'ailleurs je le fais) virer Nautilus. Le bureau Gnome ne dépend pas de Nautilus (mais Nautilus dépend de Gnome).
                                    Et je "maudirais" rpm si un jour il me suggère d'installer Nautilus.

                                    PS: ce n'est pas une critique de Nautilus, je n'utilise pas les gestionnaires de fichier graphique.

                                    > Ce que je ne comprend pas c'est surtout pourquoi dire non c'est pas bien (ou plutôt en vrai, non on en a pas besoin (pour fedora...) ) et par extension le refuser dans rpm alors que d'autres le voudraient...

                                    Je répète pour au moins la quatrième fois, je ne suis pas contre le concèpte de suggérer un autre paquet, mais je suis contre de le faire dans rpm.

                                    A une époque Fedora "suggérait" epiphany comme navigateur. Puis ça été Firefox. Ben Fedora n'a pas besoin de recompiler les paquets pour ça. Comme ce n'est pas dans rpm, Fedora n'a pas un compiler des paquets pour Fedora saveur Gnome et Fedora saveur KDE et Fedora saveur developers, etc.

                                    Je répète encore, je ne suis pas contre le concèpte de suggérer un autre paquet. Fedora, les faits le montre, n'y est pas contre non plus. Mais ça ne doit pas être fait dans rpm.
                                    • [^] # Re: dommage

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

                                      > Une dépendance optionnelle n'est pas une dépendance.
                                      > Quand penses-tu ?
                                      je dirais qu'on est vendredi aujourd'hui... ;-)

                                      mais oui, une dépendance peut être optionnelle, je ne vois pas le problème.

                                      Par exemple, sous kdesvn, par défaut il me fait le diff avec un outil kde "basique".
                                      Si j'installe kompare, il va l'utiliser pour représenter les diffs.
                                      Initialement kdesvn n'en avait pas besoin. Néanmoins, kdesvn permet de l'utiliser si celui-ci existe. Il y a bien une dépendance entre les deux, mais non obligatoire.

                                      Maintenant, avec un système sans suggestions, si le packager ne veut pas de kompare (ce qui semble correct car non nécessaire) alors l'installation de kdesvn ne me permettra pas de voir mes diffs avec. Si le packager veut lui utiliser kompare, alors il me force à l'installer et peut-être je ne le voulais pas.
                                      Il suffit alors que kdesvn viennent avec une dépendance optionnelle (je parlais bien de dépendance au sens require de rpm) et lorsque je vais l'installer il me dira que le soft marche sans kompare mais que si je veux il me propose de l'installer car kdesvn l'utilisera alors.

                                      Faire ceci en dehors de rpm est illogique. Les dépendances sont dans les .spec et à mon avis, dépendances et suggestions doivent être au même niveau .
                                  • [^] # Re: dommage

                                    Posté par . Évalué à 2.

                                    > Finalement je crois que je comprend pourquoi il y a un fork de rpm...

                                    Je viens de regarder, les suggest ont été ajoutés au format rpm.
                                    Mais rpm (de rpm.org) n'en fait rien.
                                • [^] # Re: dommage

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

                                  > Et comme c'est une dépêche Mandriva, Mandriva ne l'utilise pas (puisque de toute manière ça n'existe pas).

                                  Si si, ca existe, et c'est utilisé sur certains packages sur Mandriva.

                                  $ rpm --help
                                  [...]
                                  --suggests list capabilities this package suggests
                                  • [^] # Re: dommage

                                    Posté par . Évalué à 2.

                                    C'est un patch spécifique Mandriva.
                                    Comme je l'ai dit ailleurs, les champs SUGGESTSNAME, etc on été ajouté au format rpm (donc c'est upstream).
                        • [^] # Re: dommage

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

                          > Fedora a des "dépendances molles", c'est traitée avec le fichier comps.xml. C'est dans ce fichier qu'on trouvera les décisions "politiques". Pas au plus bas niveau.

                          Les Suggests ne sont pas plus des décisions politiques que les Requires ...

                          > Ben parfois oui. Parfois il est fait pour plusieurs distributions.

                          Peu etre que tu n'es pas au courant, mais ce n'est pas par ce que la fonctionnalité est disponible qu'il est obligatoire de l'utiliser tout le temps. Tu peux très bien ne pas l'utiliser quand tu fais des packages destinés à plusieurs distributions, ou bien prevoir que ces Suggests seront ignorés sur certaines.

                          > Même apt n'utilise pas ça à ma connaissance. Ça existe depuis des plombes, et ce n'est presque pas utilisé. C'est dire comme c'est une faux bonne idée.

                          urpmi l'utilise.
                          • [^] # Re: dommage

                            Posté par . Évalué à 2.

                            > Les Suggests ne sont pas plus des décisions politiques que les Requires ...

                            Foutaise.
                            S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.

                            > urpmi l'utilise.

                            Mais ce sont des infos qui viennent de rpm ou d'ailleurs ?
                            • [^] # Re: dommage

                              Posté par . Évalué à 2.

                              > S'il manque un require, ça ne marche pas. L'évaluation de "ça ne marche pas" n'est pas un avis polique. C'est un constat technique.

                              Même chose avec les suggest, si on les installe ça marche mieux, il y a plus de fonctionnalités puisque des composants non essentiels sont alors disponibles. C'est aussi un constat technique.

                              Par exemple: k3b fait usage de cdrecord/wodim, cdrdao et growisofs, mais il peut se passer de tous (on peut utiliser k3b pour faire de l'extraction de cd audio par exemple). Donc à ce niveau-là, utiliser le suggest pour indiquer que k3b permettra de faire plus de choses avec ces programmes est utile, et c'est bien au niveau du paquet que cette information est intéressante, parce qu'elle est vraie qu'elle que soit la distribution.
                              • [^] # Re: dommage

                                Posté par . Évalué à 1.

                                > Même chose avec les suggest, si on les installe ça marche mieux,

                                C'est ça. Firefox marche mieux avec Flash....
                                N'importe quoi.
                                • [^] # Re: dommage

                                  Posté par . Évalué à 5.

                                  Où as-tu vu un paquet firefox qui suggère flash?
                                  Tu as inventé toi-même cet exemple et depuis tu passe ton temps à le sortir comme sois-disant preuve que le champ suggest est mauvais alors que nous somme plusieurs à te répéter que l'utilisation souhaitée d'un champ suggest n'est pas celle-là.

                                  Pour te paraphraser, ce n'est pas parce que tu (avec ton exemple) viole l'usage prévu pour le champ suggest qu'il est mauvais.
                                  • [^] # Re: dommage

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

                                    Peut-être qu'il a peur d'une dérive ?
                                    Si suggest est utilisé strictement pour indiquer des trucs de sécurité ou des trucs vraiment indispensable, pourquoi pas ? Mais qui va juger de ce qui est indispensable ou pas ? Par définition, suggest sous-entend un choix de l'auteur du paquet.

                                    En même temps, suggest a bien sa place quand les paqueteurs ont acquis notre confiance, qu'on les connaît, et qu'on connaît l'esprit de la distro pour laquelle ils travaillent. Par exemple, j'ai tendance à faire confiance à Mandriva dans les paquets et l'équipement du bureau qu'ils me suggèrent d'installer... Et ça ne me dérangerait pas qu'ils me suggèrent le paquet Flash avec FF, moi.

                                    Mais pour la dérive de suggest, on pourrait presque imaginer que la dérive ultime serait de faire de suggest une distribution à lui tout seul... Après tout, une distribution Linux, c'est l'installation du noyau, avec plein de suggest autour ! :-)

                                    Je pense que suggest aura naturellement tendance à susciter la polémique et la dérive.
                                    • [^] # Re: dommage

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

                                      à mon avis, c'est un faux problème.

                                      La confiance il faut déjà l'avoir, car bon suggest peut ptetre ajouter certaines choses (mais toujours optionelles) mais si le packageur est mauvais, il peut aussier ajouter de requires qu'on ne veut pas... et là c'est pire car on a pas le choix.
                                      Donc ne pas vouloir suggest pour ceci, autant supprimer les dépendances...

                                      Ce que je ne comprend pas c'est l'animosité que suggest provoque, si certains ne veulent pas de suggest ils n'ont qu'à pas installer ce qui est suggéré et leur distrib se comportera comme sans. Et ceux qui veulent profiter des améliorations le pouront.
                                      • [^] # Re: dommage

                                        Posté par . Évalué à 2.

                                        On peut retourner le problème: pourquoi la solution des groupes ne convient pas ? C'est souple, ça fait la même chose, alors pourquoi vouloir imposer les suggestions ?

                                        RPM se veut un outil bas-niveau dans l'esprit Unix, il fait une chose et il le fait bien. Après, c'est à l'outil de plus haut niveau de proposer des fonctionnalités plus avancés comme les suggestions.
                                        Pourquoi s'amuser à complexifier RPM alors qu'il l'est suffisamment si ce n'est déjà trop ?

                                        Hein, Fedora offre les groupes (géré par le fichier comps.xml), OpenSuSE offre également des "recommendations" et des "suggestions" via son One-Click Install. (http://en.opensuse.org/Build_Service/Tutorial)

                                        Rien n'empêche Mandriva d'implémenter dans son urpmi ce mécanisme, rien ne les empêche de discuter avec les autres distributions à base de RPM d'implémenter un mécanisme commun sans forcément le foutre dans RPM.
                                        • [^] # Re: dommage

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

                                          oui et non...

                                          rpm intègre déjà les requires. Les suggest ne sont que des dépendances optionnelles et sont justement au même niveau.
                                          Franchement je ne vois pas pourquoi il y aurait une différence entre les 2.

                                          Maintenant, oui, tout comme ce sont les front-end qui gèrent l'installation des dépendances, ces front-end peuvent traiter (ou non) les suggests à leurs niveaux.

                                          Mais là ou ce serait vraiment intéressant c'est qu'il y aurait une (et une seule) façon d'indiquer les suggest pour tous les paquets rpms.
                                          Le suggest fait partie du paquet et non de l'outil de gestion du paquet ou d'installation.
                        • [^] # Re: dommage

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

                          Et après, que fais tu des suggestions ? Même apt n'utilise pas ça à ma connaissance.

                          Hein ?

                          $ sudo apt-get install p7zip-full
                          Lecture des listes de paquets... Fait
                          Construction de l'arbre des dépendances
                          Lecture des informations d'état... Fait
                          Paquets suggérés :
                          p7zip-rar
                          Les NOUVEAUX paquets suivants seront installés :
                          p7zip-full
                          0 mis à jour, 1 nouvellement installés, 0 à enlever et 1 non mis à jour.
                          Il est nécessaire de prendre 0o/1189ko dans les archives.
                          Après cette opération, 2931ko d'espace disque supplémentaires seront utilisés.
                          • [^] # Re: dommage

                            Posté par . Évalué à 2.

                            Autant pour moi.
                            Et pour synaptique ?
                            Es-ce que par exemple on peut avoir la liste des suggestions actuelles qui ne sont pas installées ?
                    • [^] # Re: dommage

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

                      Oui, et pourquoi pas un firefox avec un require sur flash ? Faut il egalement retirer les requires de rpm ?
                      • [^] # Re: dommage

                        Posté par . Évalué à 3.

                        > Faut il egalement retirer les requires de rpm ?

                        Vous êtes con ou quoi ?
                        Un require c'est ce qui est nécessaire pour que ça marche. Ce n'est pas optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, c'est nécesssaire.

                        Il y a peut-être des distributions qui ne respectent pas la signification de require, mais c'est leurs oignons. En tout cas Fedora respecte la signification de require. Si un require n'est pas nécessaire pour le bon fonctionnement du logiciel, ben fait un rapport de bug. Tu vas voir, le require sera supprimé.
                        Il y a même une chasse quasi permanente aux requires superflux.
                        • [^] # Re: dommage

                          Posté par . Évalué à 3.

                          Tu es con ou quoi, un suggest, c'est un paquet qui permet d'utiliser une fonctionalité supplémentaire. C'est optionnel, ce n'est pas un conseil, ce n'est pas une suggestion, ce n'est pas nécesssaire.

                          Il y a peut-être des distributions qui ne respectent pas la signification de suggest, mais c'est leurs oignons. En tout cas MaDistrib respecte la signification de suggest. Si un suggest ne représente pas une fonctionalité supplémentaire qui peut être ajoutée au logiciel, ben fait un rapport de bug. Tu vas voir, le suggest sera supprimé.
                          Il y a même une chasse quasi permanente aux suggest superflux.
                          • [^] # Re: dommage

                            Posté par . Évalué à 0.

                            > ce n'est pas nécesssaire.

                            Par définition, ce qui n'est pas nécessaire n'est pas requis. Donc ne mélangeons pas les Requires et les Suggests.

                            > Il y a même une chasse quasi permanente aux suggest superflux.

                            Suggest qui est un choix "politique".
            • [^] # Re: dommage

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

              > Il y a un truc qu'a deb et non rpm, c'est les suggestions.

              rpm le fait aussi maintenant.
            • [^] # Re: dommage

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

              Pour avoir utilisé les deux :
              - la rapidité de apt/dpkg à coté de yum et autres,
              - la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.

              Sinon ca joue pas énormément sur la qualité de la distro, ce qui fait la différence entre deux c'est surtout la qualité des packages, plutot que le système de package en lui même.
              • [^] # Re: dommage

                Posté par . Évalué à 2.

                la rapidité de apt/dpkg à coté de yum et autres
                C'est vrai que yum est lent, c'est le seul défaut que je reproche à fedora. Par contre, je pense qu'urpmi est assez rapide (même si je l'ai peu utilisé).
                • [^] # Re: dommage

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

                  Pour avoir utilisé yum sur Fedora Core 6 je peux te dure que y a pas photo, yum se traînait comme un fou. Il paraît qu'ils ont bossé dessus... J'espère bien, parce que j'avais le temps d'aller faire une belote pour installer un package...
                  Ça fait 4 ans que j'utilise urpmi, depuis la Mandrake 9.1, j'ai jamais ressenti la même lourdeur, il a toujours été assez rapide.
                  • [^] # Re: dommage

                    Posté par . Évalué à 3.

                    > j'avais le temps d'aller faire une belote pour installer un package...

                    Faut pas pousser.
                    Quelques exemples :
                    J'ai des mises à jour en attente en attentes :
                    # time yum update
                    [...]
                    Transaction Summary
                    =============================================================================
                    Install 0 Package(s)
                    Update 20 Package(s)
                    Remove 0 Package(s)

                    Total download size: 29 M
                    [...]
                    real 0m53.804s
                    user 0m12.287s
                    sys 0m3.598s

                    Moins d'une minute pour 29 Mo (compressé).

                    Voici un autre petit test avec une installation mini (machine virtuelle kvm).
                    time yum install openoffice.org-writer
                    [...]
                    Transaction Summary
                    =============================================================================
                    Install 125 Package(s)
                    Update 0 Package(s)
                    Remove 0 Package(s)

                    Total download size: 157 M
                    [...]
                    real 1m52.924s
                    user 0m23.623s
                    sys 0m19.857s

                    Moins de 2 minutes pour 157 Mo (compressé)

                    > j'avais le temps d'aller faire une belote pour installer un package...

                    Tu fais un belote en 1 minute ?
              • [^] # Re: dommage

                Posté par . Évalué à 5.

                > - la stabilité de la base de package debian qui se vautre quasiement jamais, alors qu'une base rpm explosé ça arrive.

                On est dans le myth. Un base rpm n'explose pas ou quasiment jamais.
                Moi ça m'est jamais arrivé alors que j'utilise du rpm depuis maintenant plus de 10 ans !
                Il y a des gens qui "explosent" leur base en utilisant les options "--nodeps" ou "--force". Mais ils l'ont cherché. Mais ce n'est pas vraiment une explosions de la base, car la base reste cohérente (c-à-d est l'image des conneries de l'utilisateur).

                Par contre rpm est fragile face au coupure de courant (dpkg aussi). Dans ce cas la base rpm n'est pas corrompue (car rpm utilise un système transactionnel), mais il y a incohérence entre ce qui est installé et ce qui est indiqué dans la base et d'autres problèmes très emmerdant.
                Rpm peut aussi être "emmerdé" en cas de manque d'espace disque. Notons que bien avant dpkg, rpm vérifie que l'espace disque est suffisant avant de faire l'installation. D'ailleurs je ne suis pas sûr que dpkg le fasse encore.

                En passant, ce n'est pas car yum (ou équivalent) écrit un message d'erreur avec "erreur dépendance manquante" que la base rpm est "explosée". Et ce n'est pas car apt "cache" les dépendances manquantes que ça base n'est jamais "explosée".
                • [^] # Re: dommage

                  Posté par . Évalué à 1.

                  > Et ce n'est pas car apt "cache" les dépendances manquantes que ça base n'est jamais "explosée".

                  des références à propos de ce mensonge honteux ?
                  • [^] # Re: dommage

                    Posté par . Évalué à 3.

                    > des références à propos de ce mensonge honteux ?

                    Je n'ai pas dit que c'était un mensonge (honteux).
                    Si tu veux la même chose avec yum, il y a le greffon yum-skip-broken.
                    C'est un choix qu'a fait apt, yum ne l'a pas fait (du moins par défaut).
                    • [^] # Re: dommage

                      Posté par . Évalué à 1.

                      Effectivement, c'est moi qui prétend que c'est un mensonge honteux parce que tu n'as toujours pas apporté la preuve de ce que tu dis. Alors je répète ma question plus clairement : où as-tu vu que «apt "cache" les dépendances manquantes» ?
        • [^] # Re: dommage

          Posté par . Évalué à 7.



          Deuxième erreur, si pendant longtemps apt-get est resté sans véritable équivalent dans le monde RPM, c'est chose révolue avec yum (et je suppose actuellement urpmi)
          Sinon, dpkg et RPM sont plus ou moins équivalent, chacun ayant des fonctionnalités avancés que l'autre n'a pas.


          Urpmi ça date de 1999 qd même , c'est pas si jeune que ça ...
      • [^] # Re: dommage

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

        J'adore le "mais loin de moi l'idée de lancer le débat" juste après une remarque bien trollistique. C'est un peu comme les spammeurs qui écrivent "CECI N'EST PAS UN SPAM" dans leurs messages de spam.
        • [^] # Re: dommage

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

          Je me permets de te répondre, je n'ai jamais dit "RPM c'est de la merde".

          J'ai uniquement donné un avis qui n'a pas la prétention d'avoir une valeur universelle.

          Ne cherchons pas le diable partout !!

          Alexandre COLLIGNON

    • [^] # Re: dommage

      Posté par . Évalué à 3.

      Trop gros, passera pas !
    • [^] # Re: dommage

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

      Pour rebondir sur ce troll avant de rajouter une info "pertinente".

      La news ne parle pas d'urpmi.recover. Je suppose qu'ils ne communiquent pas encore dessus car pour eux ce n'est pas suffisamment stable mais perso j'ai testé et c'est très pratique.

      Par exemple, hier j'ai voulu tester "conduit".

      "urpmi conduit" et là il me dit qu'il doit installer 20 paquetages supplémentaires ! Avant je faisais un copier/coller fastidieux de la liste des paquetages pour faire un "urpme" si "conduit" ne m'intéresse pas.

      Maintenant je fais "urpmi.recover -checkpoint" (Pour poser un point de retour et pour activer le système de retour arrière). Ensuite "urpmi conduit". Et si conduit ne m'intéresse pas "urpmi.recover -rollback 2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés après cette date.

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

      • [^] # Re: dommage

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

        >Ensuite "urpmi conduit". Et si conduit ne m'intéresse pas "urpmi.recover -rollback
        >2008-04-09 23:30" (heure de l'install) et ça désinstalle tous les paquetages installés
        >après cette date.

        Ca n'a quand même pas la souplesse d'un:
        apt-get --purge autoremove

        C'est dommage que urpmi ne soit pas capable de trouver tout seul ce qui n'a pas été implicitement installé par l'utilisateur.
        • [^] # Re: dommage

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

          Cela n'a pas la souplesse mais cela n'a pas non plus le même rôle.

          Si ça se trouve un équivalent au --purge existe sous rpm. Des experts sur le sujet ?

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

          • [^] # Re: dommage

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

            Pour supprimer toutes les bibliothèques inutilisées sur le système (nécessite quelques fois 2 passages) :
            urpme `urpmi_rpm-find-leaves -g`
            • [^] # Re: dommage

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

              C'est pas la même chose qu'autoremove.

              L'équivalent apt de ce que tu donnes, c'est apt-get --purge remove `deborphan`autoremove propose d'enlever les paquets installés automatiquement par apt (genre libtrucmuch quand tu installes progfoo) qui n'est plus nécessaire (genre la mise à jour de progfoo ne dépend plus de libtrucmuch).
              • [^] # Re: dommage

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

                Je connais pas bien apt-get mais urpme `urpmi_rpm-find-leaves -g` permet de supprimer toutes les bibliothèques inutilisées du systèmes (que tu appelles "installées automatiquement").

                Par exemple sur mon poste, j'avais une lib qui trainait sans raison :

                $ urpme `urpmi_rpm-find-leaves -g`
                $ désinstallation de liblua5.0-5.0.3-4mdv2008.0.i586
                $ désinstallation du paquetage liblua5.0-5.0.3-4mdv2008.0.i586


                Voila, le ménage est fait.
                • [^] # Re: dommage

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

                  Oui, j'ai bien compris, et ce n'est pas la même chose : si j'installe une bibliothèque à la main pour un programme que je compile, mais qui n'est pas utilisé par un autre package, urpme `urpmi_rpm-find-leaves -g` et la version debian utilisant deborphan vont m'enlever cette bibliothèque. Par contre, autoremove gardera cette bilbiothèque, car je l'ai installé moi-même, et c'est pas apt qui l'a installé à cause d'une dépendance.
                  • [^] # Re: dommage

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

                    Et si la lib se trouve installée par apt-get build-dep, est-ce qu'elle sera supprimée par autoremove?
  • # KDE 4

    Posté par . Évalué à 4.

    Juste pour chipoter mais :

    Dans la dépêche et ici [http://club.mandriva.com/xwiki/bin/view/Main/2008SpringRelea(...)] il est indiqué que la version de kde 4 est la 4.0.2.

    Par contre ici [http://wiki.mandriva.com/en/2008.1_Tour] et ici [http://wiki.mandriva.com/fr/Mandriva_Linux_2008_Spring_Visit(...)ée], il est indiqué que c'est la version 4.0.3.
    • [^] # Re: KDE 4

      Posté par . Évalué à 2.

      C'est bien la 4.0.3. Erreur d'étourderie sans doute.
  • # Contrôle parental et refonte du MCC (et fond d'écran)

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

    Ne pas oublier aussi la création d'un module de contrôle parental qui "identifie automatiquement tout contenu inconvenant avant d'autoriser l'accès à un site web et permet d'instituer des limites temporelles d'utilisation de l'ordinateur"

    Ainsi que la refonte du MCC (mandriva control center). Je n'ai pas testé toutes les fonctionnalités, mais le gestionnaire de paquetages a été grandement améliorée, il est possible d'utiliser le filtre "applications graphiques" afin d'épurer toutes les bibliothèques et autres dépendances, et n'avoir que les logiciels au sens "applicatif générique". Il semble que la conversion des index au format xml ait été fortement bénéfique. La rapidité d'exécution n'a plus rien à voir, qu'il s'agisse d'urpmi ou de rpmdrake. Plus besoin non plus, semble-t-il, de passer par plf puisque à la première connexion il est proposé d'installer toutes les sources nécessaires. L'applet de mise à jour ne s'affiche que lorsque une mise à jour est nécessaire, ou qu'il y a un problème. Enfin, avant il fallait choisir entre les index complets, ou réduits (moins d'info mais temps de téléchargement plus court) et maintenant seul les infos nécessaires sont téléchargées à la volée. Bref, je pense qu'il manque uniquement, pour parfaire le tableau, une série d'icônes graphiques représentant les "incontournables" pour le débutant qui cherche à installer un logiciel spécifique, tel que j'ai pu le voir dans certaines distributions dont kubuntu.

    Pour finir, tout comme la dernière fedora, la teinte du fond d'écran varie en fonction de l'heure.
    • [^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)

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

      Pour finir, tout comme la dernière fedora, la teinte du fond d'écran varie en fonction de l'heure.

      C'est peut-être un gadget inutile mais ça donne super bien, j'en suis complètement fan.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)

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

      Ne pas oublier aussi la création d'un module de contrôle parental qui "identifie automatiquement tout contenu inconvenant avant d'autoriser l'accès à un site web et permet d'instituer des limites temporelles d'utilisation de l'ordinateur"

      Ce module est disponible pour d'autre distribution ?
    • [^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)

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

      "identifie automatiquement tout contenu inconvenant"

      Qui donc est chargé de préserver notre morale et celle de nos pauvres enfants ???

      "et permet d'instituer des limites temporelles d'utilisation de l'ordinateur"

      man time.conf

      à bas la censure !
    • [^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)

      Posté par . Évalué à 2.

      > Pour finir, tout comme la dernière fedora, la teinte du fond d'écran varie en fonction de l'heure

      C'est un script bourrin à la main ou bien ils utilisent la fonctionnalité de Nautilus ?
    • [^] # Re: Contrôle parental et refonte du MCC (et fond d'écran)

      Posté par . Évalué à 4.

      A ne pas oublier non plus, l'intégration d'Elise, un media center bien sympa.

      D'un côté plus "technique", on notera la présence de composant bas niveau (kernel, drivers ...) communs avec la distribution Turbolinux. Ces éléments sont maintenants développés au sein d'un labo commun : "Manbolab". Chaque version futures de ces deux distrib's intégreront de plus en plus de composants communs au fur et à mesure de l'avancée du projet.

      Sinon, on notera aussi que tous les paquetages (ou presque) sont maintenant refait automatiquement par un bot pour chaque nouvelle version. Qq vieux paquest devaient encore migrer.

      Le contrôle parental est aussi un super nouvel outil. A tester.
  • # Intégration des outils des synchronisations

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

    Cette fonctionnalité devient vraiment nécessaire et son intégration au sein de cette nouvelle mouture est une très bonne chose.

    Avec l'essor des offres 3G+, un grand nombre d'utilisateur lambda se retrouve avec un superbe outils entre les mains, jusqu'alors difficilement utilisable avec une linux box.

    Voici un argument de plus pour une migration toute en douceur ... :D, et aussi de quoi faire plaisir à tous les geek ayant acquis se genre de portable.

    Alexandre COLLIGNON

  • # Support EEE

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

    Quelqu'un à testé le support "complet" du EEE ? Qu'est-ce que ça donne en terme de temps de démarrage ?
    • [^] # Re: Support EEE

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

      Un développeur du blog Planet Mandriva a essayé d'utiliser le mode de démarrage du Eee, mais ça enlève beaucoup de fonctions de base du init classique. Bref, le démarrage sera plus lent que la verison d'origine du Eee par défaut, pour te permettre d'installer LAMP dessus ;-)

      ⚓ À g'Auch TOUTE! http://agauch.fr

    • [^] # Re: Support EEE

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

      15) Boot and shutdown are slow compared to Xandros. Boot: 1min40s; shutdown 35s. However as noted by Adam, a Mandriva box rarely needs rebooting. Suspend-to-RAM and resume are quite fast (10~15 seconds).

      ça vient de là : http://forum.eeeuser.com/viewtopic.php?id=18287&p=12

      ⚓ À g'Auch TOUTE! http://agauch.fr

      • [^] # Re: Support EEE

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

        oui mais bon... le resume ne passe pas avec la swap en sdhc. Il faut donc la swap sur le SSD... c'est pas super conseillé.
        • [^] # Re: Support EEE

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

          Il me semble que la partition pour le suspend to disk est pas forcément une partition de swap, ca peux être une partition tout simplement inutilisé.
      • [^] # Re: Support EEE

        Posté par . Évalué à 3.

        a Mandriva box rarely needs rebooting

        oui mais un EEE en suspend to ram n'a même pas 24 h d'autonomie, alors à mon avis il vaut mieux éviter.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Support EEE

          Posté par . Évalué à 2.

          Sur un eeepc 8go avec 1 mo RAM, temps de démarrage 1 mn plus 20 s pour KDE, c'est un peu le point noir car le démarrage de Xandros est impressionnant.

          L'install d'une powerpack par mon DVD externe LaCie (le modèle lourd) a été long, de l'ordre de 3 heures. J'ai fait une install KDE par défaut sans swap. ll m'a fallu reconfigurer KRandRTray pour utiliser un écran externe, j'ai aussi immédiatement enlevé Kerry Beagle. Pour le reste ça a l'air bien, on verra un peu plus tard, mais dès le départ c'est fonctionnel: montage des clés usb, sans fl (mais pas encore essayé wpa supplicant avec le protocole de mon université...) ...
    • [^] # Re: Support EEE

      Posté par . Évalué à 3.

      Bonjour. Bravo mandriva ils ont fait du super boulot!

      après ubuntu et eeexubuntu sur eeepc 701.

      Je viens d'installer cette version sur mon eeepc avec GNOME, tout le matos est super bien reconnu, et je trouve l'installeur de mandriva très simple (niveau ubuntu, meme mieux peut etre)

      ==le cool==
      Cheese dans le dépot
      Gnome 2.22
      Ecran externe VGA bien reconnu
      Un démarrage correcte
      ....

      ==Points négatifs==
      *le wifi, il n'est pas installé par défaut (de la politique anti-proprio?) c'est tres simple à installer et ça se fait graphiquement.
      *VNC (tightVNC) C'est à revoir, l'interface est pourrite par rapport à ubuntu

      *apres la config de samba, le systeme de configuration ajoute dans le fichier /etc/fstab le partage si on veut, Il rajoute la ligne correspondante en utilisant un nom d'hôte (//Monnomd'hote/monpartage) qui n'est pas reconnu par la suite, donc le montage
      echoue après redemarrage de la session gnome.
      J'ai du bidouillé le fichier (/etc/hosts) sur ce point.

      *NFS c'est dur à configurer, le service ne demarre pas
      *Demarrage détaillé en mode texte, ce n'est pas joli
      *Le système sonore: le son de amarok n'est pas en priorité haute, ça coupe un peu quand l'ordi rame, c'est désagréable de faire souffrir le son

      En tout cas je suis globalement bien content de la bete :-) C le pied, j'avais quitté mandriva FREE il y a un an, je reviens content et pour longtemps je pense,
  • # ClearClearLooks!

    Posté par . Évalué à -5.

    très très épuré le KDE 4's configuration panel dans le 2008.1 Tour (http://wiki.mandriva.com/en/2008.1_Tour)
    -> http://wiki.mandriva.com/en/Image:20081_KDE_preferences.jpg

    en dehors de ça j'ai rompu avec Mandriva il y a quelques années, pour des raisons plus ou moins évoquées plus haut (et qui sont en partie fondées)

    par contre, je ne comprends toujours pas pourquoi une distribution française à la base n'est toujours pas capable de fournir du contenu en français sur leurs sites?
  • # apparence

    Posté par . Évalué à 5.

    Je suis en train de télécharger le torrent pour tester cette nouvelle Mandriva, mais au vu des photos d'écran, ce n'est pas ultra "sexy" : les dégradés linéaires à la fois sur les décorations de fenêtres et sur le fond d'écran, ainsi que le bleu froid et acide, cela fait vraiment trop vieillot et dépassé, où sont passés les graphistes qui ont fait les forts jolis écrans de l'an passé :

    http://images.mandriva.com/2007Spring/Screenshots/One_2007_s(...)

    Cela peut semble anodin face aux nouvelles technos très intéressantes de cette version, mais malgré tout c'est la première chose qui m'a frappé, tant sous gnome que kde, qui se retrouve à égalité à ce niveau (je ne parle même pas de kde4 qui est aussi élégant qu'une pochette de disque des années 80, mais ça ce n'est pas spécifique à Mandriva).

    En tout cas chapeau pour tout le reste !

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # mandriva : le fichier est où ?

    Posté par . Évalué à -3.

    [mode mandriva on]
    C'est vraiment surprenant l'expérience avec cette mandriva, le site est une usine à gaz incroyable dans laquelle il est complexe de se repérer, quand on arrive enfin à comprendre que spring/one/1 ca se ressemble alors on charge un lien pour voir (car entre asia et int on s'interroge : à quand des libellés simples ? ) .
    Puis comme le 1er lien est mort on poursuit , genre au 5ème ... toujours des liens morts sur les mirroirs france !!
    Euh ils dorment ou quoi ?
    Bon allez, je tente chez distri coffee ou un truc dans le genre un peu plus bas et là ouf !! ya du café et même un lien... Heureusement que j'avais prévu un wget -c car l'aprém passée le cd n'était pas encore arrivé... J'ai arrêté là les frais.
    [/mode mandriva off]
    • [^] # Re: mandriva : le fichier est où ?

      Posté par . Évalué à 4.

      tu n'as pas dû tomber directement sur la page d'accueil à mon avis, et tu as loupé les fichiers torrent... dommage

      http://www.mandriva.com/fr/telecharger

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: mandriva : le fichier est où ?

        Posté par . Évalué à 1.

        hello,
        si si c'est exactement le lien utilisé et je crois que les torrents sont l'un des choix possibles, mais pas le seul. A mon avis seuls ceux qui savent que les torrents soulagent la bande passante les prennent, notamment quand d'autres choix sont là avant . Je suis donc allé au choix le plus évident : or le choix du pays offre des mirroirs locaux aux liens http et ftp ; torrent n'est présenté qu'ensuite en bas de page et de plus comme méthode alternative ; c'est dommage en effet , même si cela à la mérite d'exister. J'aurai proposé torrent d'abord et les autres liens ensuite ;)
        Si je critique c'est car la critique est constructive. Quand à moi de telles anomalies en page de téléchargement me paraissent aberrantes (page de téléchargement trop chargée et mal agencée, une fois le pays choisi n liens vides, téléchargement anormalement long pour un simple cd ) , d'autant plus pour une société qui par ailleurs vend ses produits et devrait fignoler ces aspects de telle sorte que l'on soit tenté d'acheter si la version gratuite convaint.
        • [^] # Re: mandriva : le fichier est où ?

          Posté par . Évalué à 4.

          non le choix proposé est logique : miroir + torrent en dessous. Avant de cliquer sur un miroir on voit mieux les torrents. Ayant un client torrent (ktorrent) j'ai utilisé ce moyen, et cela a téléchargé correctement (120 kb /s). Suite à ton second message j'ai testé un miroir, free par exemple, et là cela allait encore plus vite, plus d' 1 Mo /s.

          Donc aucun problème à signaler du côté des différentes méthodes de téléchargement.

          Au niveau du site ce n'est pas le meilleur site au monde, mais il n'est pas mal fait quand même et relativement pratique à utiliser je trouve (wiki etc)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: mandriva : le fichier est où ?

      Posté par . Évalué à 1.

      Même si je ne l'utilise pas, je n'aime pas dire du mal de Mandriva.
      C'est mon premier amour "viable" (après RH, mais c'est l'époque qui voulait ça).
      Ils ont toujours été précurseurs pour faire de Linux un système utilisable au bureau et à la maison; toujours!
      Mais si le site de Mandrake était une grosse merde, celui de Mandriva est une bouse de première.

      Donc, je plussoie...et vous me moinsez.
  • # Enfin la voilà

    Posté par . Évalué à 6.

    Je suis personnellement ravi de voir arriver cette petite dernière dans la famille Mandriva.

    Encore beaucoup de nouveautés en perspective. :)

    Je suis content de voir qu'OpenOffice.org est présent sous sa toute dernière version (les transitions 3D d'Impress sont-elles inclues?).

    Quant aux trolls sur la version Powerpack, je rappelle que le paiement est dû à la présence de pilotes propriétaires pour les cartes graphiques et autres, des programmes payants (exemple, LinDVD), du support utile pour les débutant comme pour les entreprises, etc qui ne sont pas présent dans la version Libre pour des raisons évidentes.

    Histoire de troller à l'inverse: pourquoi n00buntu ne propose-t-elle pas une version de ce type qui est d'une symplicité déconcertante pour le nouveau venu dans le monde GNU/Linux? :D

    Non mais sérieusement, arrètons les trolls deb/rpm, version payante, etc... accueillons plutôt à bras ouverts cette nouvelle version d'une distribution grand-public dont la qualité n'est plus à démontrer (même s'il en existe d'autres comme OpenSuse ou Ubuntu et bien d'autres).


    Je reste fidèle à Mandriva qui sait rendre GNU/Linux accessible au grand public depuis bien longtemps.

    Je n'ai pas encore réussi à télécharger l'ISO (apparemment pas mal d'autres se sont rués comme moi sur les serveurs à l'annonce de la release :P). Je vais donc attendre un peu avant de pouvoir la tester sur mon ordinateur fixe. :)
    • [^] # Re: Enfin la voilà

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

      Bonjour,

      je viens de tester, et les transitions 3D OpenGL d'OO Impress sont bien là et fonctionnent toutes !!! Pour une fois ça fait plaisir de voir un truc qui marche sous Linux, mais dont on ne sait pas si ce sera porté un jour sur Windows ou Mac.

      Dans le même genre d'idée, en plus évolué, il y a KeyJNote, qui propose des transitions OpenGL de grande qualité, et un accès ultra rapide à l'ensemble des vignettes : je préfère désormais ça pour la visualisation (il faut convertir les fichiers en PDF avant, on perd donc des choses en en gagnant d'autres...)

      Et j'en profite aussi pour remercier et féliciter toute l'équipe de Mandriva, tout a marché out of the box sur ma machine, même Compiz-Fusion avec ma vieille carte 3D, bravo ! J'avais switché en 2003, et depuis je n'ai plus jamais eu envie de retourner sous Windows.
      • [^] # Re: Enfin la voilà

        Posté par . Évalué à 2.

        Whoah! Merci pour l'information, c'est vrai que ça fait plaisir. J'ai finalement lancé le torrent durant la nuit et je n'ai plus qu'à le graver. :D

        Je vais aussi pouvoir tester la bête en live-cd sur mon ordinateur portable.

        :D et dès la fin des examens, si tout va bien, je l'installe. :)
        • [^] # Re: Enfin la voilà

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

          j'ai pas vu les transitions 3D... c'est ou ?
        • [^] # Re: Enfin la voilà

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

          Il ne faut pas oublier pas de laisser tourner bittorrent pour aider à la diffusion des iso. Si on a arrêté bittorrent, il suffit de le relancer et il reprend son travail.

          Pour ma part, je viens de dépasser le ratio de 1.00 C'est à dire que j'ai rendu à internet plus que je lui ai demandé. J'espère bien monter à un rapport de 3 ou 4 sur les 4 images ISO de DVD que j'ai téléchargé sur ma machine.
          • [^] # Re: Enfin la voilà

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

            Sinon, on peut aussi l'acheter en version Powerpack : serveur FTP dédié pas encombré, téléchargement à la vitesse maximale de ma connexion internet (autour de 900 Ko/s, en ce qui me concerne).
            Et en plus, ça leur donne un bienvenu coup de main pour continuer à coder, et du pain pour manger.
            Je crois que personne n'a pensé à donner le lien pour l'acheter. C'est là :
            http://store.mandriva.com/product_info.php?products_id=388
            • [^] # Re: Enfin la voilà

              Posté par . Évalué à 3.

              En effet, ça leur donne un bon coup de pouce. Je suis en train d'hésiter à acheter l'abonnement Powerpack ou juste la powerpack 2008.1 .
  • # :(

    Posté par . Évalué à 2.

    putain y en a qui se font chier à faire des dépêches d' enfer, d' autres se font chier à faire des commentaires qui nous éclairent tous, les suiveurs essaient d' être dans les temps pour proposer qq chose de correct.
    Et on se rammasse vos commentaires au final
    linuxfr, c est plus ce que c' était.

    désolé des grots mots, mais franchement (...)
    • [^] # Re: :(

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

      linuxfr, c est plus ce que c' était.

      Ben si, justement :)
    • [^] # Re: :(

      Posté par . Évalué à 1.

      C'est ce qu'on appelle la liberté d'expression. Ça te déçoit peut-être, mais il reste encore cette liberté en France ; autant en profiter.
  • # Ca marche bien sur eeePC

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

    Hello,

    Testé en livecd sur un eeePC, et installé par accident*. Donc ça marche, les touches ACPI sont gérées, bien que l'OSD pour le volume soit bien trop gros (1/4 de l'écran).

    La webcam fonctionnelle directement sans avoir à l'activer dans le bios, mise en veille OK,gestion énergie ok (mieux que sous eeexubuntu), pour l'instant, je n'ai rien à dire une fois installée.

    J'ai par contre deux-trois griefs :
    - Installation par erreur : j'avais booté via un lecteur cd externe sur le live. Ma fille de 4 ans 1/2 adore jouer avec les icones, surtout les icondes rigolotes, et sait cliquer sur les boutons de la boite de dialogue. Elle a donc fait cliclic puis suivant, jusqu'au bout, et compris la sélection du mot de passe root et des comptes se fait après la copie... L'installation ne demande pas de mot de passe, et d''ailleurs un su sur la live montre l'absence de mot de passe root. J'appelle ça un trou de sécurité. Bref, tout perdu... Mais ça prouve qu'une enfant de 4 ans 1/2 ne sachant pas lire peut installer Mandriva One.

    - Devant le fait accompli, j'ai tout de même réinstallé moi-même la distrib. Impossible de choisir ext2 à l'installation ! Embetant sur le SSD de l'eeePC. Donc passage à la main, reformatage avec un bloc size de 1024.

    - j'ai voulu utiliser la distrib et le gestionnaire de paquet de mandriva. Malgré n tentatives, le téléchargement finissait par bloquer sur certains paquets de plusieurs Mo, sans reprise (j'ai parfois attendu près d'une heure). Alors je clique sur Annuler, je désélectionne quelques produits, et relance l'installation. Et bien il n'a pas pris en compte mes "déselections". Hop un bug ! De toute façon, je n'ai jamais réussi à installer.

    - Pire : en fermant le gestionnaire de paquets, la transaction continue et il y a un lock sur la base rpm... Pire encore : le Mandriva Update se déclenche parfois quand on est dans le gestionnaire, et du coup on ne peut plus rien installer durant ce temps... Mal fichu.

    - Le boot graphique est absent par défaut de l'eeePC faute d'activation du frame buffer. je vais chercher voir si c'est tout de même possible.

    Mais bon, malgré ces légers soucis, je vais continuer. Les serveurs Mandriva sont saturés en ce moment, ceci expliquant cela. C'est joli, ça marche pas mal, le matériel est parfaitement géré, rien à retoucher à ce niveau, 3D activé, pilote graphique Intel ok (problème xv des eeexubuntu absent). Moi qui suis habitué à OpenSUSE et Ubuntu, j'avoue que c'est pas mal.

    My 2 cents.
    • [^] # Re: Ca marche bien sur eeePC

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

      Mais ça prouve qu'une enfant de 4 ans 1/2 ne sachant pas lire peut installer Mandriva One.

      Je connaissais l'expression « Un enfant de 6 ans pourrait le faire », mais là, il va falloir réviser notre langage !
      Bravo à elle et toutes mes félicitations à ses parents.
    • [^] # Re: Ca marche bien sur eeePC

      Posté par . Évalué à 4.

      > J'appelle ça un trou de sécurité.

      Non, le trou de sécurité c'est d'avoir laissé un ordinateur sans surveillance dans un état où n'importe qui peut le foutre en l'air.
    • [^] # Re: Ca marche bien sur eeePC

      Posté par . Évalué à 1.

      bravo à ta fille!
    • [^] # Re: Ca marche bien sur eeePC

      Posté par . Évalué à 4.

      Bonjour Sébastien,

      Pour choisir l' EXT2 lors de la phase d' installation :
      Lors du partitionnement, choisir "partionnement personalisé".
      Puis clicker sur "expert" (cela va ouvrir différentes fonctions à différents endroits).
      Enfin clicker sur "type" et choisir "Linux NATIF" en lieu et place de EXT3.

      Voilà, peut être que cela servira ?
      En tout cas, si EXT2 est à conseillé pour le ssd (je cours relire l' article de Patrick_G sur les formats de fichiers), cela pourrait être un plus qu' il soit proposé par défaut dans le cas de cet EEEPC ??
      Tu peux ouvrir un rapport de bug, je pense, afin de proposer cette suggestion.

Suivre le flux des commentaires

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