Sortie de Fedora 14

Posté par . Modéré par Nÿco.
Tags :
39
2
nov.
2010
Fedora
Elle est là ! Elle est là ! Elle est vraiment là ! Fedora 14 est sortie ! Fedora est un système d'exploitation libre et avancé qui offre en permanence des fonctionnalités innovantes pour le plus grand nombre, avec une nouvelle version tous les six mois.

Fedora 14, nom de code Laughlin, est enfin disponible au téléchargement après des mois de travail, accompagné d'un portail rénové aux couleurs de sa communauté. Quelles sont les nouveautés de Fedora 14 ?

Pour les utilisateurs du Bureau
Une multitude de nouvelles fonctionnalités pour les utilisateurs :

  • libjpeg-turbo Charger et sauvegarder des images au format JPEG n'aura jamais été aussi rapide que sous Fedora 14 !
    libjpeg-turbo est une implémentation optimisée qui divise par deux le temps de compression/décompression des images sur les machines disposant des jeux d'instructions MMX/SSE et un léger boost (de l'ordre de 25 %) pour les autres. libjpeg-turbo étant compatible ABI/API avec libjpeg, tous les logiciels peuvent en bénéficier sans réécriture, ni recompilation. Merci à Adam Tkac.

  • Spice (Simple Protocol for Independent Computing Environments) fournit aux utilisateurs une expérience du bureau distant amélioré.
    Celui-ci pose les fondations pour la prise en charge de l'accélération matérielle graphique, du chiffrement, du curseur « matériel », mais également de l'audio. Pour le moment, le support de Spice a été intégré dans l'hyperviseur Qemu/KVM et des pilotes pour les systèmes invités X11 et Windows (XP, Vista et 7) sont disponibles. Spice est une technologie libérée par Red Hat en décembre 2009 suite au rachat de Qumranet en 2008. Qumranet est également à l'origine de l'hyperviseur KVM intégré au noyau Linux. Merci à l'équipe virtualisation de Red Hat à l'origine de ce projet.

Bien évidemment GNOME 2.32, KDE 4.5 SC et XFCE 4.6.2 sont au rendez-vous

Pour les développeurs.
Les développeurs ont été particulièrement gâtés :

  • Prise en charge de Milkymist Les développeurs pourront développer sur Milkymist, une carte de développement embarqué libre sur Fedora 14.
    Merci à l'équipe du Fedora Electronic Lab.

  • D Fedora 14 introduit la prise en charge de D, un langage de programmation système combinant la puissance et les performances de C++ et la productivité des langages modernes tels que Python et Ruby.
    L'environnement est basé sur le compilateur LDC qui repose sur l'infrastructure LLVM et la bibliothèque standard Tango, d'autres bibliothèques sont disponibles (Mango pour le réseau, Derelict pour le multimédia, etc.) sur les dépôts standard ou le dépôt D. Merci à Jonathan Mercier.

  • Mise à jour de Python 2 La version système de Python passe en version 2.7.
    Python 2.7 facilite la migration vers Python 3.1 et constitue la dernière version majeure de Python 2.x. Merci à Dave Malcolm.

  • GNUStep Un framework de développement pour le langage de programmation Objective-C.
    Merci à Jochen Schmitt.

  • Outils de débogage mémoire Le nouveau paquetage « gdb-heap » ajoute la commande « heap » à gdb qui permet d'analyser l'utilisation de la mémoire dynamique par un processus.
    Merci à Dave Malcolm qui a développé cette fonctionnalité au sein de Fedora.

  • Rakudo Star Une implémentation de Perl 6.
    Perl 6 est la dernière itération du langage Perl qui fut à l'origine de nombreuses innovations des langages de programmation. Merci à Gerd Pokorra, Christoph Wickert et Marcela Mašláňová.

Mais également un environnement de développement Gtk3, un jeu enrichi de modules pour Python3 (Qt4), la disponibilité de PySide les bindings Python Qt développé par Nokia en LGPL, etc.

Pour les administrateurs systèmes
Et nous n'avons pas oublié les administrateurs systèmes :

  • Une image Fedora 14 (AMI) sera disponible pour les utilisateurs du service de cloud computing EC2 d'Amazon, qui sortira en parallèle de la version « classique ». Merci à Justin M. Forbes.
  • ipmiutil Fedora intègre un utilitaire de gestion de serveur IPMI amélioré avec ipmiutil. Merci à Andy Cress qui est également le mainteneur upstream du projet.
  • virt-v2v facilite la migration des machines virtuelles Xen vers l'hyperviseur KVM.
  • Un dépôt Virtualization Technology Preview permet de tester les derniers développements en matière de virtualisation. Merci à l'équipe virtualisation de Red Hat.
  • Varnish a été mis à jour et apporte une meilleure mise à l'échelle ainsi que des nouvelles fonctionnalités de journalisation.
  • Apache a été mis à jour et inclus un grand nombre de modules et mises à jour de sécurité.
  • Systemd En dernier, mais pas le moindre, Fedora 14 intégre une tech preview de systemd, le système d'init nouvelle génération pour un démarrage plus rapide et une multitude de fonctionnalités avancées. Merci à Lennart Poettering qui est également le mainteneur upstream.

Et ce n'est qu'un début ! Des mises à jour de nombreux paquetages comme d'habitude seront disponibles dans Fedora 14. Une liste plus complète des nouvelles fonctionnalités intégrées à Fedora 14 est disponible sur :
http://fedoraproject.org/wiki/Releases/14/FeatureList Pour un tour rapide des fonctionnalités dans Fedora 14, visitez nos notes de versions abrégées :
http://fedoraproject.org/wiki/F14_one_page_release_notes Les notes de versions de Fedora 14 et divers guides disponibles dans différents langages sont à votre disposition sur :
http://docs.fedoraproject.org/ Les bogues connus de Fedora 14 sont répertoriés sur cette page :
https://fedoraproject.org/wiki/Common_F14_bugs

Il ne vous reste plus qu'à la télécharger. N'attendez plus ! Si vous mettez à jour depuis une version précédente de Fedora, référez-vous à :
http://fedoraproject.org/wiki/Upgrading Fedora a pris soin de faire de preupgrade une solution plus robuste et de corriger des bogues dans les précédentes versions de Fedora afin de faciliter la mise à jour vers Fedora 14.

Fedora Spins

Les spins Fedora sont des versions alternatives de Fedora, conçus pour divers usages avec une sélection d'applications ou personnalisations différentes. Ils sont disponibles à l'adresse :
http://spins.fedoraproject.org

Cela comprend les spins :
  • Mobility MeeGo est un système d'exploitation et kit de développement pour les plateformes mobiles nouvelle génération, issu de la fusion des projets Moblin et Maemo (respectivement maintenu par Intel et Nokia).
  • Sugar Un spin basé sur l'environnement d'apprentissage collaboratif Sugar.
  • KDE Un spin utilisant KDE comme environnement de bureau par défaut.
  • XFCE Un spin utilisant XFCE comme environnement de bureau par défaut.

Contribuez

Pour plus de renseignements sur les bogues connus, et des conseils sur la bonne manière de rapporter les bogues, veuillez vous référer aux notes de versions :
http://docs.fedoraproject.org

Il y a différentes manières de contribuer au-delà des rapports de bogues. Vous pouvez aider à traduire les logiciels et contenus, tester et faire des retours sur les mises à jour, écrire de la documentation, créer des graphismes, aider à promouvoir Fedora, empaqueter des logiciels libres pour les millions d'utilisateurs de Fedora à travers le monde. Pour commencer, visitez dès maintenant http://join.fedoraproject.org !

Fedora 15

Alors même que nous continuons à fournir des mises à jour pour améliorer Fedora 14, nous sommes déjà en train de développer notre prochaine version, Fedora 15 en parallèle, et ce depuis plusieurs mois déjà. Nous prévoyons une sortie à partir de fin avril 2011 : https://fedoraproject.org/wiki/Releases/15/Schedule
  • # Youpi !!!

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

    Installation dès demain au réveil !

    Si tu ne sais pas demande, si tu sais partage !

    • [^] # Re: Youpi !!!

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

      Juste à temps. Je suis passé de fc12 à fc13 hier. :-/

      J'étais quand même moins zen avec yum pour une grosse màj comme ca, que sur mon autre bécane qui est passée tout en douceur de lenny (+backports +puredyne) à squeeze. Par exemple, il faut (fallait ?) 3 fois plus d'espace disque avec yum, car il ne fait pas la décompression et le nettoyage au fur et à mesure de l'installation des packages.

      Tiens, c'est quoi le truc tout poilu qui vient de passer ?
      • [^] # Re: Youpi !!!

        Posté par . Évalué à  2 .

        La mise à jour de Fedora (l'ensemble de la distribution) n'est pas et n'a jamais été supportée en utilisant uniquement Yum. Il FAUT passer par Anaconda qui est l'installeur (ce n'est pas pour rien).
        • [^] # Re: Youpi !!!

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

          > La mise à jour de Fedora (l'ensemble de la distribution) n'est pas et n'a jamais été
          > supportée en utilisant uniquement Yum. Il FAUT passer par Anaconda qui est l'installeur

          pratique.
          • [^] # Re: Youpi !!!

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

            Dans les faits tu peux utiliser preupgrade, ça implique juste un reboot et ça fait la mise à jour proprement. Perso je fais ça comme un goret avec yum upgrade et ça marche aussi...
            • [^] # Re: Youpi !!!

              Posté par . Évalué à  1 .

              Ça marche parfois. Si ça ne marche pas et que tu fais un rapport de bug, on t'envoit bouler.
          • [^] # Re: Youpi !!!

            Posté par . Évalué à  2 .

            Yum est juste un gestionnaire de paquets, il faut passer par anaconda pour toutes les opérations qui nécessitent un traitement spécifique (un exemple simple a été la migration ext3 → ext4, par exemple. Trop dangereux de changer le système de fichier sous les pieds de l'OS en train de tourner)
        • [^] # Re: Youpi !!!

          Posté par . Évalué à  4 .

          Il faudra vraiment m'expliquer les raisons de ne pas utiliser apt...

          Par rapport a ce qui a ete dit sur cette nouvelle:

          - Yum c'est plus lent, cela s'ameliore mais c'est lent, au passage pisi qui est aussi en python va beaucoup plus vite...
          - Yum ce n'est pas fait pour les upgrades de la distribution
          - Yum ne gere pas les desinstallation vraiment proprement et laisse un gros bazard derriere lui.

          Je ne vois pas trop les avantages de ce dernier par rapport a apt sauf les delta-rpm mais c'est plus le format que l'outil donc...
          • [^] # Re: Youpi !!!

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

            De mémoire, apt pour rpm n'est plus maintenu.
            • [^] # Re: Youpi !!!

              Posté par . Évalué à  0 .

              Je sais bien mais je ne comprend pas la logique de la chose si ce n'est ne pas reprendre une techno concurrente. Je ne vois aucun avantage a Yum par rapport a apt mais c'est probablement parceque j'ai rate quelque chose non?
              • [^] # Re: Youpi !!!

                Posté par . Évalué à  6 .

                > si ce n'est ne pas reprendre une techno concurrente

                apt ne supporte que le format dpkg, apt4rpm est un portage réalisé par Conectiva. Ça n'a jamais été un projet bien supporté (Conectiva a préféré développé smart, le projet est resté longtemps sans mainteneurs), et niveau performances, il n'a rien à voir avec son parent (en 2006: yum était déjà 2x plus rapide et avant même le parseur de métadonnées en C).

                L'intérêt de yum c'est son architecture extensible qui permettent son utilisation un peu partout dans l'infrastructure Fedora, ce qui aurait été plus difficile avec apt4rpm ou aurait nécessité de réécrire en grande partie l'outil.

                Entre un fork foireux et un outil activement maintenu, le choix est vite vu.
                • [^] # Re: Youpi !!!

                  Posté par . Évalué à  2 .

                  Ok l'outil est maintenu mais il n'a aucun reel avantage donc cela me semble bizarre.

                  L'intérêt de yum c'est son architecture extensible qui permettent son utilisation un peu partout dans l'infrastructure Fedora

                  Je dois avouer que je ne comprend absolument pas ce que tu racontes la.
                  • [^] # Re: Youpi !!!

                    Posté par . Évalué à  6 .

                    Yum est utilisé par les utilisateurs mais également par les mainteneurs de la distribution. Tout les outils pour développer la distribution sont construit autour de yum (installeur, générateur d'images, serveurs de compilation, génération de chroot etc ...), il est important que l'on puisse rajouter facilement des fonctionnalités à yum.
                    Pour l'utilisateur, ça permet une plus grande flexibilité, les plugins rajoutent des options de configuration, de nouvelles commandes.

                    Toi, tu ne vois peut-être pas l'intérêt mais ça n'est pas le cas des mainteneurs et de la plupart des utilisateurs.
                    • [^] # Re: Youpi !!!

                      Posté par . Évalué à  2 .

                      ce n'est pas que je n'en voyais pas l'utilite c'est que je ne comprennais pas ce dont tu parlais!
          • [^] # Re: Youpi !!!

            Posté par . Évalué à  -1 .

            Tout ceux qui ecrivent après ce commentaire se sont fait troller...
          • [^] # Re: Youpi !!!

            Posté par . Évalué à  2 .

            Yum c'est plus lent

            J'aimerai bien voir des données factuelles, basées sur des benchmarks sérieux des dernières versions, qui puissent étayer cette affirmation.
            Car il ne faudrait que ce qui a été vrai un moment devienne juste un poncif, une idée reçue.

            Est-ce que apt gère les "delta-rpms" ou quelque chose d'équivalent, qui permet de gagner un temps considérable lors des mises à jours ?
            • [^] # Re: Youpi !!!

              Posté par . Évalué à  2 .

              Ça date d'un an mais j'ai trouvé ça http://blog.christophersmart.com/2009/06/24/yum-still-on-the(...) au moins il y a toujours les scripts pour faire les tests de son côté.
              • [^] # Re: Youpi !!!

                Posté par . Évalué à  3 .

                Si on tient à comparer les performances brutes de yum et apt-*, il faudrait d'abord désactiver le rafraichissement du cache et le chargement des plugins qui peuvent ralentir le démarrage de yum.
                Rien qu'avec les options -C et --noplugins, je divise de 4 à 10 fois, le temps de recherche d'un paquet, donc au final, l'écart de performance entre yum et apt-* doit être très faible. J'ai même observé des cas où yum était même plus réactif qu'apt-get (cache récent, peu de plugins installés etc ...)
                • [^] # Re: Youpi !!!

                  Posté par . Évalué à  4 .

                  Je ne suis pas d'accord, il faut comparer les logiciels dans leur configuration initial.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Youpi !!!

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

              Est-ce que apt gère les "delta-rpms" ou quelque chose d'équivalent, qui permet de gagner un temps considérable lors des mises à jours ?

              vraie question : J'aimerai bien voir des données factuelles, basées sur des benchmarks sérieux des dernières versions, qui puissent étayer cette affirmation.
              Car il ne faudrait que ce qui a été vrai un moment devienne juste un poncif, une idée reçue.


              Notamment la place prise sur les miroirs lorsqu'il y a par exemple 5 mises à jour d'un paquet de OOo (au hasard) et le temps que cela prend d'effectuer le calcul de dépendances supplémentaires (côté client cette fois-ci).
            • [^] # Re: Youpi !!!

              Posté par . Évalué à  3 .

              C'est purement empirique et peu précis mais pour ma part, à chaque fois que je donne sa chance à Yum "parceque dans cette version promis-juré, Yum est vachement plus rapide qu'avant", je suis consterné par le temps qu'il lui faut pour installer le moindre bidule.

              Je suis également consterné par le temps qu'il lui faut pour installer plusieurs gros bidules.


              Pour faire la "même chose" avec une Debian-like c'est beaucoup plus rapide.

              Après si il faut passer du temps à comprendre le bousin et à réinventer son paramétrage par défaut pour obtenir des performances à peu près acceptables, c'est qu'il y a un très grave problème ...

              BeOS le faisait il y a 15 ans !

              • [^] # Re: Youpi !!!

                Posté par . Évalué à  3 .

                Après si il faut passer du temps à comprendre le bousin et à réinventer son paramétrage par défaut pour obtenir des performances à peu près acceptables, c'est qu'il y a un très grave problème ...

                Comme tu dis c'est soit problematique soit pas tres user -friendly et en contradiction avec les affirmations que apt c'est complique a cause de sa semantique.

                Ce que j'ai pu voir aussi c'est que c'est lent juste pour faire un upgrade (l'equivalent de update pour apt) avec juste 3 repos. Alors ou c'est subjectif car je ne chronometre pas mais generalement la subjectivite est un bon indicateur de lenteur (malheureusement)
            • [^] # Re: Youpi !!!

              Posté par . Évalué à  1 .

              Pas chez moi :(

              Testé sur 2 machines différentes, (un core2 e4500 et un core i7 920QM) et la reconstruction des paquets d'après les deltas se traine à environ 500 Ko/s en pointe, ma connexion ADSL est plus rapide.

              Je vote pour grâce à l'économie de bande passante et de ressources serveur, mais ça rame...
              • [^] # Re: Youpi !!!

                Posté par . Évalué à  2 .

                pas mieux, avec un amd x4 955 et un ligne adsl à 1,2 mo/s
                habitué à aptitude sur debian sid, j'ai essayé f13 pour "changer"

                Certes, les delta-rpm m'impressionnent toujours autant de part la faible quantité à télécharger, mais après, houlala, qu'est ce que c'est lent! Et ça n'est pas compensé par le dl rapide des delta-rpms
                J'ai quand meme tenu 4 jours :D (j'ai battu mon propre record avec yum)
                On va voir avec fedora 14, l'espoir fait vire :)
                • [^] # Re: Youpi !!!

                  Posté par . Évalué à  1 .

                  Moi je vois la différence, j'utilise du FreeWifi et les miroirs doivent aussi apprécier !
  • # question

    Posté par . Évalué à  2 .

    comment est ce que l'on fait pour rajouter un depot avec la GUI? Sous Gnome ou KDE dans la partie configuration il y a moyen de les activer mais je n'ai pas trouve la methode pour rajouter un nouveau depot.
    Ca marche sans probleme en rajoutant ce qu'il faut dans /etc/yum.repos.d mais c'est pas tres "user friendly".
    Autrement dans les tests que j'ai fait avec une machine virtuelle ca semble pas trop mal. Lorsque j'aurai un peu de temps a perdre je tenterai l'installation pour de vrai.
    • [^] # Re: question

      Posté par . Évalué à  3 .

      La façon "standard" d'ajouter un dépot est d'installer un rpm (qui va remplir /etc/yum.repos.d/ ).
      Typiquement, ça sera une url et le navigateur lancera automatiquement le programme qui va bien.
      • [^] # Re: question

        Posté par . Évalué à  3 .

        ok mais comment on fait si on veut rajouter un logiciel propose sur les depots de fedorapeople? Quel est le rpm qu'il fut installer pour avoir acces au reste du depot?
  • # Il faut vraiment que je change de distrib

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


    libjpeg-turbo Charger et sauvegarder des images au format JPEG n'aura jamais été aussi rapide que sous Fedora 14 !
    libjpeg-turbo est une implémentation optimisée qui divise par deux le temps de compression/décompression des images sur les machines disposant des jeux d'instructions MMX/SSE et un léger boost (de l'ordre de 25 %) pour les autres. libjpeg-turbo étant compatible ABI/API avec libjpeg, tous les logiciels peuvent en bénéficier sans réécriture, ni recompilation. Merci à Adam Tkac.


    ça maintenant... c'est vraiment un truc qui me manque.... ou pas. Non mais franchement à part l'aspect technique qui peut être intéressant, qui aujourd'hui est intéressé par une lib qui charge/sauvegarde plus vite les JPEG ?

    Alexandre COLLIGNON

    • [^] # Re: Il faut vraiment que je change de distrib

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

      qui aujourd'hui est intéressé par une lib qui charge/sauvegarde plus vite les JPEG ?

      Les gens qui vont sur le Web? Ceux qui ont un appareil photo compact?

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

    • [^] # Re: Il faut vraiment que je change de distrib

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

      Vu l'utilisation actuelle de JPEG, si c'est intéressant :
      - Images faisant plus d'1 Mo de nos jours
      - Des centaines d'images dans un répertoire.
      - création des thumbails.
      Ben oui, la photo numérique est passée par la...

      Bon, maintenant, en faire 3 lignes dans une annonce de sortie d'une distro entière, ça fait effectivement un peu peur sur le contenu de cette version...
      • [^] # Re: Il faut vraiment que je change de distrib

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

        Franchement, je préfère mille fois une version comme ça, qui corrige des bugs et fait des petites améliorations un peu partout, qu'un énorme changement qui casse tout.
        • [^] # Re: Il faut vraiment que je change de distrib

          Posté par . Évalué à  4 .

          En même temps, présenter ainsi, le choix ne se discute pas. Il parait difficile de ne pas être d'accord car je connais peu de monde qui préfèrerait "un énorme changement qui casse tout' :-)
        • [^] # Re: Il faut vraiment que je change de distrib

          Posté par . Évalué à  4 .

          Oui en fait quand Fedora ne change rien, n'apporte pratiquement rien à l'utilisateur, et sort une nouvelle version c'est bien mais quand il s'agit des autres c'est juste du marketing.

          Alors là j'ai envie de poser une question mais je vais laisser à quelqu'un d'autre le soin de la poser à ma place
          http://linuxfr.org//comments/926189.html#926189
          • [^] # Re: Il faut vraiment que je change de distrib

            Posté par . Évalué à  2 .

            En même temps, Fedora 14 arrive avec le protocole Spice, systemd certes pas encore par défaut (plus par frilosité qu'autre chose d'ailleurs) et pas mal de nouveautés pour les développeurs et administrateurs (le support officiel d'EC2 ça représente pas mal de boulot) qui font également partie de notre cible.

            On a migré toute l'infrastructure de CVS à git ce qui a demandé un temps d'adaptation non négligeable pour bon nombre de contributeurs, on a mis en place, les dépôts personnels, il y a eu une refonte du portail, GNOME3 a été repoussé à 2011, pour un cycle d'à peine 5 mois. La note positive est que la composition des images a été nettement moins ardue que d'habitude pour la béta et la finale (pour laquelle, il n'y a eu qu'une RC du jamais vu pour Fedora).


            Pour répondre à la critique, même en période de vaches maigres, Fedora ne se contente pas de mettre à jour les paquets et d'apposer un label "nouveau", il y a quand même quelques innovations, et Fedora 15 promet d'être beaucoup plus rock'n'oll.
            • [^] # Re: Il faut vraiment que je change de distrib

              Posté par . Évalué à  1 .

              S'il y a tant de nouveautés coté utilisateur pourquoi ne pas les avoir explicitées dans la news?


              Pour répondre à la critique, ..., il y a quand même quelques innovations, ...


              lesquelles à part les 2 que tu as cité.
              Et encore:
              Les images se chargent plus vite ma bonne dame et pis Kévin pourra vous aider tous les jours sans prendre le thé chez vous.

              En conclusion quel intérêt pour un utilisateur de base à passer à la 14.
              Ceci justifiait t'il une version ?

              Le passage à Git, il s'en tamponne, la montée de version des langages et des outils de dev, ou d'apache pareil.


              Vraiment je me demande ce qu'il y a de différent par rapport à la jolie critique pointée en lien si ce n'est un parti pris.
              A moins que ce ne soit l'effet rolling release.
              • [^] # Re: Il faut vraiment que je change de distrib

                Posté par . Évalué à  1 .

                Je ne suis pas d'accord avec toi. Il y a pas mal de changement dans la partie KDE avec le passage a KDE 4.5.2. Les activites sont enfin utilisable, digikam passe a la version 1.4 avec pas mal d'amelioration (perso j'aime bien la fonction de recherche des photos suivant leurs emplacement geographiques) etc

                Apres Gnome n'evolue plus depuis longtemps (enlever des options est une evolution mais bon pas dans le sens attendu ici) et donc comme le dit un des fedoriens la prochaine release a de grande chance d'etre rock'n roll avec l'integration de gnome3. Je sens que soit l'on va bien rigoler car ca va casser comme KDE4 soit on va pleurer car Gnome3 sera comme Gnome2 avec encore moins d'options et un petit changement d'interface (gnome-shell le pendant des activites de KDE4 ou unity un windomaker like).

                Avec un peu de chance la grande nouveaute de Gnome3 sera gimp2.8.
                • [^] # Re: Il faut vraiment que je change de distrib

                  Posté par . Évalué à  3 .


                  Il y a pas mal de changement dans la partie KDE avec le passage a KDE 4.5.2. Les activites sont enfin utilisable, digikam passe a la version 1.4 avec pas mal d'amelioration (perso j'aime bien la fonction de recherche des photos suivant leurs emplacement geographiques) etc


                  Ca c'est de base dans KDE.
                  Ah mais attends j'ai ma réponse toute faite aussi:

                  "
                  Donc le meilleur atout du logiciel libre, c'est une distribution générique sans innovations ?
                  Le rôle premier d'une distribution est certes de fournir un ensemble cohérent de paquets mais également de faire avancer les choses.
                  "
                  La suite ici:
                  http://linuxfr.org//comments/926201,1.html
                  • [^] # Re: Il faut vraiment que je change de distrib

                    Posté par . Évalué à  1 .

                    Le role d'une distribution est, pur moi, certes d'amener des innovations, mais surtout de fournir un ensemble coherent et stable. Ce qui n'est plas le cas de Ubuntu Maverick par exemple qui a introduit xorg 1.9 comme des bourrins avec pas mal de problemes connus mais non corrige pour la sortie.

                    Si Fedora a voulu faire une sorte de LTS pour cette version pourquoi pas. Visiblement ca va casser du petit bois la prochaine version donc autant avoir une version pas trop ancienne vers qui pointer les utilisateurs.
                  • [^] # Re: Il faut vraiment que je change de distrib

                    Posté par . Évalué à  2 .

                    j'avais pas encore vu ton lien .Bon ben c'est du General tout crache pas tres grave et en deux ans il a pu evoluer non? Et voir les bienfaits d'avoir une version un peu plus stable avant une autre qui va etre tres experimentale.
              • [^] # Re: Il faut vraiment que je change de distrib

                Posté par . Évalué à  3 .

                Rien n'oblige l'utilisateur à faire la mise à jour, F13 est supporté jusqu'à la sortie de F15 + 1 mois.
                Certes, la plupart des nouveautés de F14 n'intéressent pas le grand public mais la différence majeure avec la distribution que tu mentionnes est le public visé: Fedora cible un public technophile et sensible à la thématique libriste, Ubuntu le grand public.
                Pour le public concerné, les nouveautés mentionnés restent pertinentes.

                Pour revenir sur la fameuse critique que tu me reproches, je ne vois aucune contradiction. Notre créneau, c'est faire avancer les technologies libres, même si on a calé la voile, avec F14 le contrat est toujours respecté. Si on prétendait être les leaders du bureau (presque) libre et qu'on se contentait de mettre à jour les paquets pour certaines versions, je ne dirais pas mais ça n'est pas le cas (remarque qu'à force de les critiquer, Canonical a fini par se sortir les doigts du cul: le projet ayatana promet de réaliser tout ou partie des revendications de celle-ci même si il faudra attendre 2011 pour observer des changements concrets).
    • [^] # Re: Il faut vraiment que je change de distrib

      Posté par . Évalué à  6 .

      Moi ça m'intéresse énormément. Sur un vieux PC on voit très bien la différence !
      Et d'ailleurs libjpeg-turbo et KDE SC 4.5 sont les 2 seuls trucs qui m'intéressent de près dans cette F14.

      Et puis quand on peux améliorer les performances de son PC gratuitement je suis plutôt pour. Plutôt que d'acheter un Core i7...
  • # Comment font ils ?

    Posté par . Évalué à  1 .

    Oui, je me pose des questions sur leur "avance" par rapport à Debian.
    Exemple: Digikam-1.5, introuvable chez Debian, même en instable ou expérimental est pourtant bien présent dans la dernière Fedora.
    http://www.digikam.org/drupal/node/539
    https://admin.fedoraproject.org/pkgdb/applications/Digikam?_(...)
    http://packages.debian.org/search?keywords=digikam&searc(...)

    Idem pour KDE-4.5

    "L'art est fait pour troubler. La science rassure" (Braque)

    • [^] # Re: Comment font ils ?

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

      Chez fedora on ne patch pas dans tous les sens et on a pas le processus d'acceptation des paquets le plus strict et contraignant de là création ?

      En bien ou en mal, je ne juge pas.
    • [^] # Re: Comment font ils ?

      Posté par . Évalué à  10 .

      * Fedora bosse principalement upstream. S'il faut casser la compatibilité avec le driver bidule proprio, c'est fait et basta. Aux drivers proprios bidule de suivre le libre. Le libre n'a pas à se brider avec du proprio.

      * Contrairement à ce que dit tcourbon, tout n'est pas accèpté chez Fedora, il y a des règles. Pour être un mainteneur reconnu, il faut faire ses preuves. Si un paquet n'est pas maintenu ou mal maintenu, il est viré.

      * Contrairement à Debian, Fedora a des obectifs raisonnables. Fedora ne permettra jamais toutes les combinaisons possibles de mise à jour avec Yum (mise à jour d'un système actif) car même si c'est possible, c'est trop casse couille et ça bride trop. Il y a l'installeur Anaconda pour ça (qui bosse sur un système inactif). C'est un peu contraignant pour l'utilisateur, mais techniquement c'est justifié.

      * Fedora n'hésite pas à "tout casser". Il n'y a pas de "rolling distribution" chez Fedora. Une distribution est alpha (ça explose de partout), puis beta, puis rc, puis final, puis maintenu. Debian se fait chier avec testing, etc.

      * J'y reviens, mais Fedora a des objectifs raisonnables. Certains font des propositions, raisonnables au premier abord, mais chiantes à maintenir. Fedora n'en veut pas, c'est viré. L'ambition technique de Fedora est d'avoir des solutions clean (même si ça prend du temps à être développé). Les solutions techniques de Fedora étant clean, elles se retrouvent chez les autres distributions. Il y a très peu de "bricolage sans avenir" chez Fedora. Il en faut, mais Fedora le tient à un niveau faible. Ainsi la "force de frappe" de Fedora est principalement dans le R&D (recherche et développement ; en upstream notamment) et pas dans la maintenance de bricolages (ce que fait beaucoup Debian).

      * J'y reviens encore, Fedora est raisonnable. Fedora ne va pas forcker Firefox par exemple ni faire son propre système de détection de matériel.

      Il y a toute une philosophie chez Fedora et beaucoup de pragmatisme (mais en restant libre). Ce n'est pas évident à comprendre, mais ça donne des résultats sur le long terme.
      • [^] # Re: Comment font ils ?

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

        >Fedora ne va pas forcker Firefox par exemple ni faire son propre >système de détection de matériel.

        Tu te fous de notre gueule là ? C'est bizarre, j'ai pas eu souvent à bosser sur fedora, mais à l'époque de hotplug (du temps de devfs donc), y'avait un truc de merde qui s'appellait kudzu, qui à chaque boot mettait le bordel dans la conf réseau alors que y'avait rien à toucher et que hotplug avait fait son taf...
      • [^] # Re: Comment font ils ?

        Posté par . Évalué à  6 .

        Dis, tu pourrais justifier un minimum tes critiques systématiques envers Debian ? Parce que là, je ne vois pas du tout de quoi tu parles, surtout quand tu parles de "bricolages" alors que Debian est justement reconnue pour ses choix et sa capacité technique à les assumer.
  • # 6 mois d'utilisation déjà

    Posté par . Évalué à  10 .

    Ça fait déjà 6 mois que j'utilise Fedora (avec l'arrivée de Fedora 13 en fait).


    Ce que j'aime :

    - Les nouveautés. J'aime bien l'idée de Fedora de mettre en avant les nouveautés issues du monde des logiciels libres. On peut ainsi profiter des toutes dernières avancées et ne pas avoir l'air d'être à la traine.

    - La stabilité. Bien qu'utilisant des logiciels assez jeunes Fedora 13 n'a pas trop planté. Certes j'ai eu des plantages de GNOME durant un transfert NFS ou un plantage de Flash dans Firefox qui fait planter tout Metacity et divers autres bugs mais dans une certaine mesure l'ensemble est positif.

    - L'intégration. Tout est configuré dès l'installation. On dispose de pas mal d'outils pour configurer le système sans avoir besoin de la ligne de commande. On est averti de l'arrivée de nouvelles mises à jour, plymouth offre un écran de démarrage agréable, le pare-feu se configure en deux clics, on peut facilement envoyer un rapport de bug, l'outils se chargeant de télécharger les paquets qui vont bien, etc..

    Du coup on passe son temps à vraiment utiliser son système plutôt que de passer des plombes dans la configuration de ce dernier.

    Bien sûre ce n'est pas tout positif, parfois ça ne fonctionne pas. Par exemple, un NetworkManager qui se déconnecte de façon intempestive du Wifi après une mise en veille (ou qui refuse de se connecter) et où il faut ruser avec un déchargement de module et un redémarrage du service. Ou encore le bluetooth qui détecte les appareils mais ne va pas plus loin. Ou un pulseaudio vraiment trop intrusif...



    Ce que je n'aime pas :

    - Yum, et la gestion des paquets en général sous Fedora. Certes je clique sur un RPM et ça s'installe tout seul. Mais Yum comment dire ? C'est super lent, à chaque opération il faut qu'il jette un œil sur le net. Fedora m'espionnerait-il ? Il installe tout et n'importe quoi mais n'aime pas faire le ménage.

    # yum install monSuperLogiciel
    | Please wait while yum is sending your password to the Fedora team...
    \ You don't ask for that but let me look for an update...
    - Hum, what can I do now... Oh yes your software... Lets install it !

    Installation:
    monSuperLogiciel
    monSuperLogiciel
    dépendance1
    dépendance2
    dépendance3
    dépendance4
    dépendance5

    Taille totale des téléchargement : 500 M

    # yum remove monSuperLogiciel
    | Oh you want to remove a software? Just a moment please I'm reading some news on LinuxFr...

    Suppression:
    monSuperLogiciel

    Installed size: 0.5 M
    PS: I let you look for the installed dependances, I've something to do on the net.


    Je n'aime pas le fait que Yum veuille tout le temps se mettre à jour sans que l'on ne demande quoi que ce soit. Au moins que cela soit fait par une tâche cron mais quand je veux installer un logiciel j'aimerais que ça aille plus vite. De plus les dépendances sont laissées sur le système et les outils pour les retrouver sont vraiment inutiles.

    Je n'aime pas non plus le update qui est en fait un upgrade.

    La recherche de logiciels est chaotique. Yum affiche tout et n'importe quoi et on se perd dans les résultats.

    Bref moi qui aime contrôler finement ce que j'installe sur mon système avec Yum c'est impossible. Au bout de 6 mois je suis bon pour une réinstallation complète.

    Sur ce point vive APT !

    - Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent. Du coup il faut jongler entre les différents dépôts pas toujours très net. Si je veux éditer du MP3 sur Fedora, je ne peux pas avec les paquets du dépôt officiel. Audacity n'étant pas compilé avec le support du MP3.

    - La mise à jour. Debian m'a habitué à juste changer un mot pour passer d'un système à l'autre. Sur Fedora, une mise à jour se traduit par la gravure d'un nouveau CD.

    - Le panel GNOME. Ce n'est pas forcément lié à Fedora mais le panel GNOME me fatigue à toujours réorganiser les éléments qui le compose. Cela arrive surtout lorsque j'ai branché (ou débranché) un écran.

    - La gestion du multi-écran. Encore une fois pas directement lié à Fedora mais j'utilise deux écrans au quotidien. Et malheureusement, cela n'est pas reconnu comme deux écran mais bien comme un seul grand écran. Cela se traduit par la perte d'une fenêtre ou du pointeur de la souris dans l'écran ayant la plus petite résolution.

    Avec GNOME, il ne faut surtout pas déplacer les icônes du bureau sous peine de ne plus les revoir quand on débranchement le deuxième écran. En effet, GNOME positionne ses icônes de façon relative aux bords de l'écran. Donc si on déplace ceux-ci, leur position sera hors de notre écran principale lorsque l'écran secondaire sera débranché.

    Et bien sûre, le support de la détection à chaud d'un nouvel écran. xrandr améliore la chose mais il est tant que dès que je branche mon écran que celui-ci soit configuré automatiquement.


    Il y a sûrement des points positifs ou négatifs que j'ai oubliés mais le principal est là. Fedora reste cependant un système que j'aime utiliser. Certain point me font manquer Debian mais je vais donner une autre chance à cette nouvelle sortie avant de me décider.
    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  0 .

      > La mise à jour. Debian m'a habitué à juste changer un mot pour passer d'un système à l'autre. Sur Fedora, une mise à jour se traduit par la gravure d'un nouveau CD.

      pourquoi ne pas utiliser preupgrade ?
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  4 .

        Parce que d'après un commentaire plus haut ça marche quand ça veut ?
        C'est pas supporté ?
        Si t'envoie un rapport de bug tu te fais envoyer bouler ?

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: 6 mois d'utilisation déjà

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

          Non non non. D'ailleurs la confusion vient d'un commentaire faux (ou alors extrêmement ambigü au point de paraître faux) d'IsNotGood, ce qui m'étonne vu qu'on parle d'un point technique de Fedora.

          Je sais pas pourquoi il dit que preupgrade c'est à tes risques et périls vu que c'est LA solution recommandée pour mettre à jour une Fedora...

          Ce qui est indiqué comme « si ça pète il te reste ta bite, ton couteau, et tes yeux pour pleurer » c'est un gros yum upgrade de porky après avoir modifié les dépôts. Ce qui est recommandé est preupgrade. Quant à graver le CD de la nouvelle version pour démarrer dessus et màj, OK ça doit marcher mais euh osef vu qu'il y a preupgrade (ou alors faut avoir du temps à perdre pour faire comme ça).
    • [^] # Re: 6 mois d'utilisation déjà

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

      > Yum et son accès internet
      c'est assez irritant parfois, mais tu peux utiliser l'option -C pour empêcher ça. Apt reste plus rapide, mais j'aime la flexibilité de yum (le fait de pouvoir mixer les releases facilement par exemple)

      > Le manque de paquets
      Ce que tu mentionnes (le non support du mp3) n'est pas lié à une paresse des packagers, mais à une décision morale de fedora. Si tu installes les dépôts rpmfusion, tu as accès à tous les paquets pour lire du mp3 etc. Peut être pas autant que debian, mais pas mal quand même.

      > La mise à jour
      Tu n'es pas obligé de graver un CD pour mettre à jour, preupgrade fait ça très bien depuis ton système existant.

      > Le panel GNOME
      En effet, pas lié à fedora du tout, fedora s'applique à livrer les logiciels aussi proches de l'upstream que possible. Donc le panel gnome qui sait pas bien gérer les changements de résolution, c'est la "faute" de gnome :)

      > La gestion du multi-écran
      Ceci dépend beaucoup de ta carte graphique. XRandr est supporté par les pilotes libres (intel, nouveau, ati etc.). Perso le hotplug marche tout seul quand je branche un écran sur ma carte intel. Si tu utilises le driver nvidia proprio... C'est à tes risques, sous fedora qui n'a pas choisi de le supporter.
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  7 .

        Ce que tu mentionnes (le non support du mp3) n'est pas lié à une paresse des packagers, mais à une décision morale de fedora.

        Plutot une decision technique de se conformer a la loi US et ignorer les pays ou la loi est moins contraignante. J'appellerais pas ca de la paresse, mais c'est un choix qui permet de simplifier la gestion du PR, de la distrib et des mirroirs.

        Et le choix moral, quand ils signent des accords de licence pour certains brevets et payent leur detenteurs pour permettre la redistribution, c'est quand meme un peu du foutage de gueule.

        La raison serait plutot que les codecs son et audio, c'est pas une priorite pour leur marche cible (les entreprises) et donc c'est idiot de claquer de la tune la-dedans. Quand c'est au niveau bases de donnees, la morale passe vite a la trappe...

        Donc le panel gnome qui sait pas bien gérer les changements de résolution, c'est la "faute" de gnome :)

        Mmmmmh, il me semble qu'une boite se felicitait il n'y a pas longtemps d'etre un des contributeurs majeurs a Gnome, mais je ne me souvient plus du nom. Ca va surement me revenir, mais il me semble que ca commence par un R.
        • [^] # Re: 6 mois d'utilisation déjà

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

          > Plutot une decision technique de se conformer a la loi US et ignorer les pays ou la loi est moins contraignante.

          Ce que tu décris est une décision légale, pas technique.

          Fedora est une association administrativement située aux USA, il faut donc qu'elle en respecte la loi, c'est pas plus compliqué que ça.

          > Et le choix moral, quand ils signent des accords de licence pour certains brevets et payent leur detenteurs pour permettre la redistribution, c'est quand meme un peu du foutage de gueule.

          Bon, c'est bien beau de se moquer des pays où les brevets logiciels obligent à faire n'importe quoi, mais plutôt que de dépenser ton énergie ici tu devrait aller soutenir la Quadrature.

          Pour ce qui est de Red Hat, on ne peut pas vraiment mettre en doute leur engagement contre les brevets logiciels (une petite recherche rapide te le confirmera). Ignorer les brevets logiciels, qui font partie de leur loi, ce n'est pas une méthode pour lutter contre (autant que le piratage de MS Office n'est pas une méthode pour lutter contre son monopole).
          • [^] # Re: 6 mois d'utilisation déjà

            Posté par . Évalué à  2 .

            Bon, c'est bien beau de se moquer des pays où les brevets logiciels obligent à faire n'importe quoi, mais plutôt que de dépenser ton énergie ici tu devrait aller soutenir la Quadrature.

            Le rapport avec la phrase que tu cites au dessus?

            Sinon, perso, la Quadrature et tout ce qui tourne autour, c'est pas pour moi (trop politise), et de toute facon, j'habite plus en France depuis un moment (ici les groupes de pression contre les brevets ont pas besoin de quemander pour pouvoir continuer a vivre).

            (une petite recherche rapide te le confirmera)

            Une recherche rapide te confirmera aussi qu'ils ont bien signe des accords de licence, en payant (on sait pas combien, c'est vire des copies des accords dispo au public) quand ca touchait a leur business. Ils avaient le choix de virer la fonctionnalite (comme il le font pour le MP3 et les codecs videos) et pourtant ils ont choisi de payer.

            Je ne met pas en doute leur engagement contre les brevets logiciels, seulement leurs decisions qui varient selon que c'est important (on paye pour utiliser des trucs brevetes) ou pas (on vire tout) pour leur business, et donc la fragilite de l'excuse "c'est brevete" pour la non-fourniture de codecs MP3 & x264
            • [^] # Re: 6 mois d'utilisation déjà

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

              > Une recherche rapide te confirmera aussi qu'ils ont bien signe des accords de licence, en payant

              Les brevets logiciels posent aussi un problème que tu n'as peut-être pas vu : s'il faut acquérir une licence (même pour 1 centime), ça bloque la redistribution, ce qui est contraire à la GPL (v2).

              Avec les brevets sur le mp3 & co, on ne peut pas payer une fois (même une grosse fois) et couvrir non seulement les utilisateurs directs mais aussi ceux à qui ceux-ci auraient redistribué la version.
              Le mode de fonctionnement des BL est complètement opposé à celui du LL, on n'y peut rien.

              La seule chose que peuvent faire les distribs c'est :
              - ne pas inclure le MP3, et proposer un mode de récupération légal (par exemple les codecs Fluendo, ou les codecs libres classique pour ceux en dehors des pays où les brevets logiciels ont cours)
              - ignorer le problème, ce qui est tout à fait légal si on est domicilié en dehors de ces mêmes pays

              Je ne connais pas cette autre histoire de brevets dont tu parles (la recherche rapide n'a rien donné), mais ce que tu disais au-dessus c'est que Red Hat a payé pour permettre la redistribution. On est donc pas du tout dans le même cas.
              • [^] # Re: 6 mois d'utilisation déjà

                Posté par . Évalué à  1 .

                Les brevets logiciels posent aussi un problème que tu n'as peut-être pas vu : s'il faut acquérir une licence (même pour 1 centime), ça bloque la redistribution, ce qui est contraire à la GPL (v2).

                Le mode de fonctionnement des BL est complètement opposé à celui du LL, on n'y peut rien.


                Tu te contredit plus bas lorsque tu dis que Redhat a paye pour permettre la redistribution (ce qui est vrai).

                A noter que ca ne concerne que le projet en question (plus ses ancetres et derives). Donc projet concurrent utilisant ces memes choses brevetees = baise.

                Ca ne marche en effet que si la personne detentrice des brevets est prete a accepter un deal pour autoriser la redistribution (mais ca tu peux pas le savoir sans demander...)

                Je ne connais pas cette autre histoire de brevets dont tu parles (la recherche rapide n'a rien donné)

                "redhat patents settlement" dans Google.

                Ca concerne JBoss et Redhat contre Firestar & Datatern (une analyse au hasard ici: http://www.groklaw.net/article.php?story=20080611191302741 )

                Plus recemment, ils ont eu des problemes avec Acacia - oui, les memes contre qui ils avaient gagne la derniere fois - ( http://blog.internetnews.com/skerner/2010/10/red-hat-settles(...) ) et ont trouve un accord (et n'ont pas l'air de trop vouloir en parler...).
                • [^] # Re: 6 mois d'utilisation déjà

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

                  Je reformule :
                  * Les détenteurs de brevets sur le mp3 ne veulent pas accorder de licence redistribuable. Donc déjà, là c'est mort pour les distribs concernées par les BL.
                  * Les licences sur les brevets achetés par RH, eux, permettent la redistribution : pas pareil du point de vue de la conformité GPL.

                  C'est plus clair là ?

                  Ensuite, comme tu le fais remarquer, ça ne couvre pas les autres entités qui utiliseraient les mêmes choses brevetées. Mais là, franchement, la seule solution c'est de faire sauter le brevet, ou de racheter la boîte. La vraie bonne solution étant de pousser pour abandonner les brevets logiciels, et là-dessus RH fait ce qu'il peut.
        • [^] # Re: 6 mois d'utilisation déjà

          Posté par . Évalué à  3 .

          Mmmmmh, il me semble qu'une boite se felicitait il n'y a pas longtemps d'etre un des contributeurs majeurs a Gnome, mais je ne me souvient plus du nom. Ca va surement me revenir, mais il me semble que ca commence par un R.

          Radiola ? Ils ont contribué le bouton de réglage du volume, je crois.
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  3 .

        Si tu installes les dépôts rpmfusion, tu as accès à tous les paquets pour lire du mp3 etc. Peut être pas autant que debian, mais pas mal quand même.

        sauf que rpmfusion est tout casse ou en tout cas inaccessible...
    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  3 .

      Mais Yum comment dire ? C'est super lent, à chaque opération il faut qu'il jette un œil sur le net.

      "yum --cacheonly". Voir aussi /etc/yum.conf.
      "yum makecache" pour mettre TOUT le cache à jour (par défaut yum ne met à jour que le nécessaire pour la tache qu'il a à réaliser).

      Il installe tout et n'importe quoi

      C'est un peu du pipo. Ce qui est installé est justifié même si ce n'est pas insdispensable. Par exemple, des images de fond ne sont pas indispensables. Yum (en fait quand on réalise un "yum groupinstall") installe les images de fond. Les utilisateurs s'attendent à avoir des images de fond par défaut sur leur système.

      NB: Tu as peut-être parfois utilisé "yum groupinstall" (typiquement via anaconda). Les groupes sont un niveau supérieur du gestionnaire de paquet. Il y a aura des éléments non indispensable mais que les utilisateurs attendent. "yum groupinstall XFCE" installe un bureau typique XFCE, pas le minimum.
      On remarquera que Fedora n'utilise quasiment pas les meta-paquets (c'est fait avec les groupes et ils sont assez peu nombreux).
      Sauf spécifié (ou par un programme qui utilise yum), yum n'utilise pas les groupes.

      Je n'aime pas le fait que Yum veuille tout le temps se mettre à jour sans que l'on ne demande quoi que ce soit.

      C'est une question de sécurité. Beaucoup de distributions s'en foutent, pas du tout Fedora. Chaque fois que yum fait une opération, il le fait avec les mises à jour. Si une mise à jour est disponible, il peut y avoir un patch de sécurité, Fedora l'installe. Si un dépôt est cassé au niveau des dépendances, ça peut arriver mais ça reste très exceptionnel, c'est corrigé rapidement et yum remarchera comme prévu dans un ou deux jours. Il y a aussi "--skipbroken".

      De plus les dépendances sont laissées sur le système et les outils pour les retrouver sont vraiment inutiles.

      Il y a des outils pour ça, mais j'ai arrêté de les utiliser tant c'est "sans intérêt". Pour faire court, Fedora s'en fout des dépendances laissées et qui ne sont pas utilisées. Si ce n'est pas utilisé, ça ne doit pas déranger (sinon faire un rapport de bug). En passant, c'est ce fait que Windows 7 ; il installe tout, ça ne bouffe que de l'espace disque. Le BIG problème est comment savoir qu'une lib n'est vraiment pas utilisée ? Si tout est contrôlé par yum(rpm), ça peut encore aller. Mais il y a aussi le problème des greffons (chargement dynamique). Désinstaller une lib que yum (rpm en fait) ne croit pas utilisée peut casser un programme. Donc Fedora ne fait pas le forcing à ce niveau.

      Je n'aime pas non plus le update qui est en fait un upgrade.

      C'est effectivement discutable, mais c'est la politique de Fedora. Ce n'est pas le cas de RHEL (qui a les mêmes outils mais une autre politique).


      Certains "défauts" de Fedora n'en sont pas vraiment. C'est une "politique". On y adhère ou pas, mais il faut au moins la comprendre.
      • [^] # Re: 6 mois d'utilisation déjà

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

        >Certains "défauts" de Fedora n'en sont pas vraiment.

        C'est quand même fou, t'es un un peu le PBPG de RedHat, quoi qu'on puisse dire sur ton OS, c'est toujours faux, en fait, Fedora c'est farpait un peu comme Windows...

        J'adore ma distrib mais des défauts elle en a, à commencer par son gestionnaire de paquet (qui parfois me donne envie de me taper la tête contre les murs)... Debian a le meilleur gestionnaire de paquets mais à d'autres défauts... Bref, rien n'est parfait, et surtout pas Fedora (le surtout c'est pour te faire bondir :p)
        • [^] # Re: 6 mois d'utilisation déjà

          Posté par . Évalué à  4 .

          C'est quand même fou, t'es un un peu le PBPG de RedHat, quoi qu'on puisse dire sur ton OS, c'est toujours faux, en fait, Fedora c'est farpait un peu comme Windows...

          Le truc c'est que quand tu suis le developpement d'un OS, tu comprends les choix fait par la distrib et ce qui parait stupide pour une personne non informé a un sens.

          Typiquement le coup de la lib non utilisé, il explique le pourquoi du choix réalisé.

          Et le coup du yum -C, c'est pareil.

          Les differents choix de Debian doivent tous avoir une justification.

          Je ne trouve pas qu'il fasse de la mauvaise fois (comme PBPG d'ailleurs)
      • [^] # Re: 6 mois d'utilisation déjà

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

        De plus les dépendances sont laissées sur le système et les outils pour les retrouver sont vraiment inutiles.

        Il y a des outils pour ça, mais j'ai arrêté de les utiliser tant c'est "sans intérêt". Pour faire court, Fedora s'en fout des dépendances laissées et qui ne sont pas utilisées. Si ce n'est pas utilisé, ça ne doit pas déranger (sinon faire un rapport de bug). En passant, c'est ce fait que Windows 7 ; il installe tout, ça ne bouffe que de l'espace disque. Le BIG problème est comment savoir qu'une lib n'est vraiment pas utilisée ? Si tout est contrôlé par yum(rpm), ça peut encore aller. Mais il y a aussi le problème des greffons (chargement dynamique). Désinstaller une lib que yum (rpm en fait) ne croit pas utilisée peut casser un programme. Donc Fedora ne fait pas le forcing à ce niveau.


        Heu en quoi la comparaison avec wIn7 est utile ? C'est la référence en matière d'OS ? Moi je trouve pas ça normal. J'aime les OS qui utilisent des gestionnaires de dépendances intelligent qui font bien le ménage. Sur debian quand je retire qqch il retire les dépendances non utilisées. ça mange moins d'espace, et c'est plus propre. Et en plus ça donne un côté plus fini.
        A chaque annonce d'une nouvelle version de Fedora, il y a toujours un hic dans la nouvelle version : yum trop lent, et pas propre.

        Dommage pour un truc qui veux être à la pointe de la R&D.
        • [^] # Re: 6 mois d'utilisation déjà

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

          ça mange moins d'espace, et c'est plus propre

          Et ça évite de démarrer des services qui ne sont plus utilisés.

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

      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  5 .

        Mauvaise foi spotted !

        Oser dire que yum planté un ou deux jours à cause d'un dépôt pourri c'est acceptable, ça me fait franchement rigoler. Dire que désinstaller les dépendances non-utilisées ça peut casser des paquets, c'est se foutre de la gueule du monde (je détaille après). Dire que les défauts de Fedora sont en fait une politique, c'est ce qu'on appelle du ridicule achevé (surtout après avoir tant craché sur les supposés défauts des autres distribution).

        Sur cette histoire de paquet et de greffons, il y a deux cas. Partons du problème d'un paquet A qui peut charger dynamiquement une lib d'un paquet B et un paquet C qui dépend du paquet B. Si B a été installé via C, c'est que l'utilisateur ne s'en servait pas pour A donc on peut désinstaller B si on désinstalle C. Si l'utilisateur se servait de B, il l'a installé directement et donc, quand C est désinstallé, B ne l'est pas. En tout cas, c'est comme ça que fonctionne apt et ça me semble être assez naturel. Il n'y a aucun problème. Donc Fedora (ou IsNotGood) se fout de la gueule du monde.
        • [^] # Re: 6 mois d'utilisation déjà

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

          > Donc Fedora (ou IsNotGood) se fout de la gueule du monde

          Attaque directe spotted. Restons clames SVP, le projet Fedora ne se fout pas de la gueule du monde (c'est assez dur à faire quand on y pense), et je pense qu'IsNotGood est sincère.

          Ce que tu décris est arrivé relavitement récemment dans yum (2 versions de mémoire), avant on ne stockait pas si un paquet était installé sur demande utilisateur ou par dépendance.

          Donc maintenant qu'on a l'info, le plugin dont on parlait peut avoir le comportement que tu décris (j'ai jamais essayé personnellement mais je crois que c'est comme ça que ça marche).
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  1 .

        Merci pour ces explications mais je n’adhère toujours pas à Yum.

        Un autre exemple, imaginons que j'ai oublié d'enlever le proxy de la configuration de Yum. Il va essayer de se connecter au serveur sans succès et en essayer un autre. Le problème est qu'il est impossible de l'arrêter avec un simple ^C... Ou du moins il faut insister.

        Je n'ai pas d'exemple en tête mais je me rappelle avoir vu Yum (sans groupinstall) installer des dépendances qui certes ont un rapport avec le logiciel installé mais dont la nécessité me met en doute...

        Concernant la mise à jour, on peut en effet utiliser preupgrade mais ce n'était pas la politique de départ de Fedora et je sentais mon système tellement sale qu'il me semblait nécessaire de faire une installation toute fraîche.

        En parlant d'installation, je viens d'installer la nouvelle sortie. Je télécharge donc le Desktop Live CD et clique sur Installer sur le disque. Je me retrouve de base avec pas moins de 1071 paquets installés dont plein de logiciels que je ne souhaite pas forcément comme un serveur HTTP ou autre.

        Certes c'est plus simple pour l'utilisateur qui ne veut pas s'embêter et qui a tout sous la main tout de suite. Mais n'est-il pas possible de donner le choix à l'utilisateur sans pour autant délaisser les ceux qui ne veulent pas se poser de questions ? A aucun moment il ne m'a été demandé de choisir les logiciels que je voulais installer.

        Je n'aime pas la nouvelle mode qui dit que puisque la taille des disques augmente, on peut se permettre de les remplir. De la même façon, on se retrouve avec des logiciels qui se traînent car de toute façon maintenant les PC ont suffisamment de mémoire...
        • [^] # Re: 6 mois d'utilisation déjà

          Posté par . Évalué à  2 .

          Ta critique sur les live-Cd c'est malheureusement valable pour toutes les distributions que j'ai pu voir. Ce n'est pas specifique a Fedora.
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  2 .

        En passant, c'est ce fait que Windows 7 ; il installe tout, ça ne bouffe que de l'espace disque

        Euh tu n'as pas pire comme exemple? Moi ca me pete les c.... de voir qu'une installation minimale d'un systeme me prend 10 Gigs sur mon disque dur. Non je ne considere pas cela comme etant un detail. Dire que je croyais que le libre essayait de corriger les mauvaises pratiques de ce genre de systeme...
    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  2 .

      - La mise à jour. Debian m'a habitué à juste changer un mot pour passer d'un système à l'autre. Sur Fedora, une mise à jour se traduit par la gravure d'un nouveau CD.

      On n'est pas obligé de graver une CD. Je ne vais pas expliquer les différentes possibilités ici.
      M'enfin, graver un CD tous les 6 mois, ce n'est pas la mer à boire.

      - Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent. Du coup il faut jongler entre les différents dépôts pas toujours très net. Si je veux éditer du MP3 sur Fedora, je ne peux pas avec les paquets du dépôt officiel. Audacity n'étant pas compilé avec le support du MP3.

      Fedora est (vraiment ; dans la pratique) libre.
      RpmFusion répond à la majorité de ses problèmes : http://rpmfusion.org/
    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  1 .

      > - Le manque de paquets. Les paquets sont rares sur Fedora et en plus ils en refusent.

      Le manque de paquets tient essentiellement dans le fait que Fedora (dans son aspect communautaire) est plus jeune que Debian (8 ans contre 17+). Le retard se comble petit à petit, de release en release.
    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  1 .

      # yum install monSuperLogiciel
      Installation:
      monSuperLogiciel
      dépendance1
      dépendance2
      dépendance3
      dépendance4
      dépendance5
      Taille totale des téléchargement : 500 M

      # yum remove monSuperLogiciel
      Suppression:
      monSuperLogiciel
      Installed size: 0.5 M
      PS: I let you look for the installed dependances,
      "yum --remove-leaves erase monSuperLogiciel" ? (ou forcer dans /etc/yum/pluginconf.d/remove-with-leaves.conf, de mémoire)

      Je n'aime pas non plus le update qui est en fait un upgrade.
      Ah tiens, marrant moi je me dis exactement l'inverse quand je passe d'une Fedora à un Ubuntu...

      Mais Yum comment dire ? C'est super lent, [...]
      Y'a pire : zypper sous openSUSE ! (j'aime bien mais j'ai dû installer yum en parallèle :p )
      • [^] # Re: 6 mois d'utilisation déjà

        Posté par . Évalué à  5 .

        Ah tiens, marrant moi je me dis exactement l'inverse quand je passe d'une Fedora à un Ubuntu...

        Sauf que yum est bien plus recent que apt et franchement faire l'inverse de apt au niveau des commandes c'est vraiment pour dire "moi je fais pas pareil".
        • [^] # Re: 6 mois d'utilisation déjà

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

          Ça avait fait effectivement pas mal de bruit au début du développement de Yum. Mais c'était il y a très longtemps, et comme c'est celui qui code qui décide... (yum c'était un projet indépendant de Fedora à l'époque).
          • [^] # Re: 6 mois d'utilisation déjà

            Posté par . Évalué à  2 .

            Puisque tu sembles etre un historien de yum: pourquoi avoir finalement choisi ce logiciel plutot que apt? Quels ont ete les raisons technique?
            • [^] # Re: 6 mois d'utilisation déjà

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

              Apt pour RPM était reconnu comme un gros hack assez compliqué à maintenir. Il y a beaucoup de choses dans APT qui supposent que derrière c'est DPKG qui installe, et résultat en plus d'être compliqué il y avait des fonctionnalités de RPM qu'on ne pouvait pas utiliser.
              En plus, APT c'est beaucoup de lignes de code, c'est pas si simple que ça en a l'air.

              Tout ça c'est de mémoire, mais vu que le développeur a jeté l'éponge, et que c'était manifestement un bon (il a fait smart après), j'imagine que ça devait être particulièrement chiant à maintenir.
            • [^] # Re: 6 mois d'utilisation déjà

              Posté par . Évalué à  6 .

              La manière dont Red Hat a choisi yum est bien documentée : ils ont pris tous les apt-like pour rpm de l'époque, fait un audit de code, et pris celui qui avait un code propre et extensible (et embauché son auteur). yum a gagné car :

              1. il était codé proprement (pas encore optimisé, mais bien structuré). On peut optimiser du bon code, c'est très difficile de maintenir du code rapide mais bordélique

              2. il utilisait le moteur de résolution de dépendances de rpm au lieu d'utiliser un algo différent lors de la résolution réseau, et espérer que rpm soit d'accord à l'installation (apt-rpm). Cela a permis :
              a. de reprendre l'existant rpm sans rupture (simple bon sens pour Red Hat qui était n°1 sur son marché
              b. d'écrire des règles de packaging rigoureuses, claires et détaillées, puisqu'il n'y a aucune ambiguïté sur le moteur de règles à respecter (tout passe par librpm et que par librpm), ce qui a permis d'assainir et améliorer la qualité de la distribution en général

              3. il était intégrable simplement dans les autres outils Red Hat (Anaconda est en python, comme son nom l'indique). C'est complètement invisible pour les utilisateurs, mais aujourd'hui tous les outils Fedora/Red Hat (Anaconda, PackageKit, la ferme de compilation, Spacewalk, Satellite, Cobbler j'en passe et des meilleures) font appel à l'infrastructure yum et ça marche très bien.

              Yum est un choix qui s'est révélé plus que judicieux avec le temps. Red Hat n'avait pas besoin d'un client d'installation type apt-rpm (ils avaient déjà leur propre bouse, up2date qui a heureusement été abandonnée) mais d'une vraie brique d'infrastructure avec laquelle ils pourraient construire d'autres applications. Le yum vu par l'utilisateur est juste un frontal shell, c'est une toute petite partie de ce que yum fait pour Fedora.

              D'ailleurs Suse/Novell (qui avait aussi besoin de construire des infras autour de rpm) a écarté comme Red Hat tous les clients apt-like de l'époque, et a fini par écrire le sien de zéro. C'est ce qui leur a permis ensuite de construire https://build.opensuse.org/
        • [^] # Re: 6 mois d'utilisation déjà

          Posté par . Évalué à  3 .

          > franchement faire l'inverse de apt au niveau des commandes c'est vraiment pour dire "moi je fais pas pareil".

          C'est surtout que la sémantique des commandes apt-get est pourrie pour la majorité des utilisateurs finaux:
          update ==> mise à jour du cache | mise à jour du système
          upgrade ===> mise à jour du système | passage à la version supérieure
          dist-upgrade ===> passage à la version supérieure, ça reste cohérent avec les autres commandes

          je trouve la sémantique yum plus logique:
          makecache ===> mise à jour du cache (fait automatiquement avec un timeout configurable ==> pour la majorité des utilisateurs, c'est le comportement par défaut souhaitable)
          update ===> mise à jour du système
          upgrade (via un plugin officiel) ===> passage à la version supérieure
          Pour le passage à la version supérieure, Fedora n'étant pas une rolling release, il est recommandé d'utiliser un assistant (soit l'installeur Anaconda ou preupgrade) pour gérer les éventuelles incompatibilités et nettoyer le système des paquets obsolète. Pour ceux qui utilisent yum, il y a différentes possibilités, soit utiliser le switch --releasever avec la commande update pour définir la version (ou bien installer le paquet fedora-release correspond ce qui revient au même), soit utiliser le plugin upgrade-helper qui ajoute la commande upgrade.

          Par ailleurs, tu peux désactiver le rafraichissement automatique du cache dans la configuration de yum:
          metadata_expire = never

          La jeunesse de yum par rapport à apt-get n'est pas une raison pour suivre les "travers" de celui-ci. Zypper d'OpenSuSE a un comportement similaire, la principale différence est que le rafraichissement automatique du cache est désactivé par défaut (il faut rajouter l'option auto-refresh pour l'activer).
          • [^] # Re: 6 mois d'utilisation déjà

            Posté par . Évalué à  2 .

            Je ne vois absolument aucun probleme a la semantique de apt par contre tes definitions de ce quelles font me semble legerement fausse:

            - update : resynchronisation des fichier d'index repertoriant les paquets disponibles.
            - upgrade : installation de la plus recentes de tous les paquets presents sur le systeme
            - dist-upgrade : meme chose que upgrade en y ajoutant une gestion intelligente des changements de dependances dans les nouvelles versions des paquets.

            tire du man apt-get
            • [^] # Re: 6 mois d'utilisation déjà

              Posté par . Évalué à  2 .

              > Je ne vois absolument aucun probleme a la semantique de apt
              La sémantique est cohérente mais elle n'est pas intuitive pour un nouvel utilisateur. D'autant plus, si il n'a jamais utilisé de système unix-like, faut expliquer les concepts de paquets, dépôts, cache (ou index si tu préfères), etc ...

              > tes definitions de ce quelles font me semble legerement fausse
              bonnet blanc et blanc bonnet, c'est du pareil au même.
              • [^] # Re: 6 mois d'utilisation déjà

                Posté par . Évalué à  2 .

                La sémantique est cohérente mais elle n'est pas intuitive pour un nouvel utilisateur. D'autant plus, si il n'a jamais utilisé de système unix-like, faut expliquer les concepts de paquets, dépôts, cache (ou index si tu préfères), etc ...

                Avec synaptic (le plus vieux GUI pour les systemes de packages) ou les nouveau trucs tel les software center les nouvels utilisateurs ont enormement d'outils pour tout faire sans ecrire une seul fois apt-get et depuis bien plus longtemps que l'existence de yum.
                Niveau nouvel utilisateur il faudrait que vous ameliorer enormement les rajouts de depots car ce n'est absolument pas intuitif.

                bonnet blanc et blanc bonnet, c'est du pareil au même.

                Ah ouhais? et je te souhaite bon courage pour faire une mise a jour du systeme avec uniquement apt-get update.
                • [^] # Re: 6 mois d'utilisation déjà

                  Posté par . Évalué à  2 .

                  > Niveau nouvel utilisateur il faudrait que vous ameliorer enormement les rajouts de depots car ce n'est absolument pas intuitif.

                  On peut difficilement faire plus simple que de cliquer sur un lien qui installe un paquet qui configure tout aux petits oignons.

                  > et je te souhaite bon courage pour faire une mise a jour du systeme avec uniquement apt-get update.

                  gni ? de quoi tu parles ?
                  • [^] # Re: 6 mois d'utilisation déjà

                    Posté par . Évalué à  2 .

                    On peut difficilement faire plus simple que de cliquer sur un lien qui installe un paquet qui configure tout aux petits oignons.

                    Si c'est fournit car pour l'exemple au dessus (peoplefedora) je n'ai pas trouve le rpm pour.

                    gni ? de quoi tu parles ?

                    je te cite:

                    update ==> mise à jour du cache | mise à jour du système
              • [^] # Re: 6 mois d'utilisation déjà

                Posté par . Évalué à  2 .

                C'est sûr qu'il vaut mieux pour le " nouvel utilisateur " aller chercher la version vérolée de SuperMacro.exe sur telechargez.com ...

                Ce genre d'arguties me laisse pantois.

                Sedullus dux et princeps Lemovicum occiditur

          • [^] # Re: 6 mois d'utilisation déjà

            Posté par . Évalué à  4 .

            Bah, pour la simplicité et la rapidité, rien ne vaut les pkgtools sous Slackware :
            installpkg --> installe
            removepkg --> désinstalle
            upgradepkg --> met à jour le(s) packet(s)

            avec un rsync en tâche cron sur les miroirs …

            Sinon pour les feignants il y a slackpkg :
            slackpkg update --> mise à jour du cache
            slackpkg install, remove, upgrade --> même comportement que les pkgtools
            slackpkg upgrade--all --> mise à jour de tous les logiciels
            slackpkg clean-system --> nettoie le système de tous les logiciels non officiels

            Pour le passage à la version supérieure :
            #Changer la version dans le fichier /etc/slackpkg/mirrors
            slackpkg update
            slackpkg install-new
            slackpkg upgrade-all
            slackpkg clean-system

            Bref un système simple, robuste, rapide et où il n'y a aucun problème de dépendance :)
        • [^] # Re: 6 mois d'utilisation déjà

          Posté par . Évalué à  -1 .

          J'utilise principalement yum pour installer/supprimer des logiciels ou les mettre à jour. Et pour ces opérations je le trouve plus logique et plus simple que apt.

          Sérieux, faire 2 commandes pour mettre à jour son système avec apt je vois pas l'intérêt. Qu'est ce que j'en ai à foutre qu'il y ai une mise en cache ? Je veux mettre à jour le système : "yum update" et on en parle plus. C'est quand même plus simple que 'apt-get update"... attente... "apt-get upgrade".
          • [^] # Re: 6 mois d'utilisation déjà

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

            Actuellement, il y a un cron chez Debian qui fait régulièrement un apt-get update. Tu peux raisonnablement faire apt-get upgrade sans aucun soucis, la liste des paquets sera à jour.

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

    • [^] # Re: 6 mois d'utilisation déjà

      Posté par . Évalué à  1 .

      Pour moi, je venais de Mandriva (je retournerai peut-être sur Mageia ...) et je suis passé à Fedora 13.
      Bon, la lenteur de yum ne m'a pas choqué (utilisateurs urpmi vous me comprendrez) mais le manque de paquets, déjà plus (incroyable le boulot fait par la communauté Mandriva à ce niveau d'ailleurs).
      J'ai aussi été désagréablement surpris de découvrir qu'ils avaient adapté d'OpenOffice à leur sauce (ça m'a pas sauté aux yeux à l'install).
      Une remarque aussi: les fichiers de conf ne font pas 300 lignes commentées par les draktools: ça peut aider à comprendre certains dysfonctionnements, mais ça oblige aussi à RTFM pour trouver les options manquantes: un mal pour un bien dans les 2 cas.
      Ah j'allais oublier SE-Linux qui est encore plus casse-machin que msec AMHA.

      PS: qui peut me dire comment on empêche package-kit de me re-proposer à chaque fois des updates non souhaitées?
  • # Pourquoi je n'ai jamais installé fédora.....

    Posté par . Évalué à  2 .

    J'ai déjà essayé fédora dans virtualbox et malheureusement j'ai eu le même feeling qu'avec Suse : lourdeur et lenteur. Je ne dis pas ça pour critiquer, mais je n'ai jamais compris pourquoi le système me semblait si peu réactif. Est-ce une distribution réservée à du matériel très performant ou est-ce moi qui m'y prend mal ?
    • [^] # Re: Pourquoi je n'ai jamais installé fédora.....

      Posté par . Évalué à  8 .

      Hmm c'est peut etre parce que tester la ``reactivite'' d'un
      environement graphique avec virtualbox n'est pas tres realiste sur la
      dite ``reactivite'' ?
      • [^] # Re: Pourquoi je n'ai jamais installé fédora.....

        Posté par . Évalué à  2 .

        Peut etre mais sur une meme machine je me suis apercu que dans Virtualbox une debian ca va vite tres vite, une ubuntu c'est lent comme la mort et une fedora c'est entre les deux. Donc cela ne veut rien dire mais j'ai toujours trouve cela curieux.
        • [^] # Re: Pourquoi je n'ai jamais installé fédora.....

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

          Hmm, je vais te donner un indice, VirtualBox, ca rame en parti à cause des accès disque, donc plus la distrib a de services en fonctionnement, plus ça va ramer...

          Installe tout et n'importe quoi sur ta Debian, tu vas voir si ça va pas ramer...

          ps: quand je parles services, je parles bien sur /etc/*.d mais aussi /usr/share/autostart
  • # Spin Mobility / Meego

    Posté par . Évalué à  3 .

    Le spin avec Meego n'existe pas. Ils en parlent dans l'annonce qui a été reprise un peu partout (dont cette dépêche), mais c'est apparemment dû au fait que les personnes en charge de l'annonce n'ont pas été prévenues de son absence par le SIG Mobility ( http://fedoraproject.org/wiki/Mobility ). La décision semble avoir été un peu tardive (j'ai lu mi-octobre quelque part) mais je n'ai pas réussi à mettre la main dessus... en tout cas rien d'explicite sur la mailing list dédiée (pas très fournie).

    De plus, certains ont des difficultés pour utiliser Meego avec une installation en parallèle d'autres environnements de bureau.
    • [^] # Re: Spin Mobility / Meego

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

      depuis hier, je cherche comme toi et je ne trouve pas ce spin sur le net. Ni le Fedora NetBook spin. Dommage ...

      peut-on passer à l'interface mobli/meego depuis une fedora "classique"
  • # Comme d'habitude n'upgradez pas sous virtual box....

    Posté par . Évalué à  1 .

    Encore une fois, comme a chaque upgrade depuis fedora10 pas de serveur-x au reboot.
    Bon comme d'habitude un ptit system-config-display --reconfigure et c'est reparti...

    He ben NON, system-config-display est maintenant deprecated...

    Si quelqu'un a une solution pour retrouver le bureau graphique dans ces conditions je suis preneur.....
    Pas encore trouve les bon mots clefs pour la solution qui doit bien exister quelquepart.....parce que bon, je dois pas être le seul avec ce problème a la con quand même.....

Suivre le flux des commentaires

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