Test de Fedora 10 Cambridge

Posté par  (site web personnel) . Modéré par patrick_g.
Étiquettes :
7
10
jan.
2009
Fedora
La distribution Fedora 10 "Cambridge" est sortie en novembre dernier comme annoncé sur LinuxFR, et j'ai réalisé un test de cette dernière avec les captures d'écran d'usage.

J'ai pour l'occasion téléchargé la version x86_64 sur mon portable (Intel Core 2 Duo T7300 avec 2 Go de RAM et carte vidéo Nvidia 8xxx mobile) et mon netbook (Acer Aspire One avec 1.5 Go de RAM et carte vidéo Intel).

Fedora 10 Cambridge contient une belle liste de nouveautés : PackageKit (ainsi que RPM 4.6 encore plus rapide et plus propre), Plymouth (le remplaçant de RHGB), GNOME 2.24, KDE 3.5.10 et 4.1.2, Firefox 3.0.4 (3.0.5 dans les mises à jour), noyau 2.6.27 (apportant la prise en charge de plus de 250 nouveaux types de caméras et de beaucoup de cartes wifi), OpenOffice.org 3.0 finale, NetworkManager (utilisé dès l'installation de Fedora), Eclipse 3.4 et Xorg 7.4.

Je vous invite donc à consulter ce petit survol des nouveautés à la sauce FRLinux (petit rappel, comme pour la plupart des distributions testées, le but est de fournir un avis rapide sur une distribution pour l'utilisateur ou le décideur pressé).

Aller plus loin

  • # coin

    Posté par  . Évalué à 5.

    Merci pour ce test qui m'a appris plusieurs petites choses, étant nouvel utilisateur de Fedora.

    Quelques remarques en passant :
    * "projet Fedora dans sa dixième incantation"
    on incante des distrib maintenant ? :) heureusement qu'on ne les décante pas encore !

    * "Cette nouvelle version compote"
    de pomme ? :)

    * "Vous pouvez donc installer le RPM de configuration de Fusion (marche également pour Fedora 8 et 9). Vous pourrez alors installer les paquets dont vous avez besoin tels que Flash et la lecture de DVDs."
    Flash ne fait pas partit de ce repo, il est dans celui d'adobe.
  • # Problèmes réseau

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

    En installant la FC10 j'ai eu la surprise de constater que le network manager inclu dans la version finale incorporait un bug majeur : impossible de configurer un réseau non DHCP !
    Cela est particulièrement génant pour les installations en réseau. Dans ce cas le bug est totalement bloquant. J'ai du me rabattre sur une installation depuis un DVD puis vadrouiller dans les fichiers de configs pour y mettre les bonnes valeurs que le GUI refuse de transcrire !

    Ce bug me paraît tellement énorme que j'ai du mal à comprendre comment il a pu passer le stade des alphas, betas, et RC.
    Je raconte cette petite histoire parce que je me demande dans quelle mesure elle signale une forme de déclin (lié à la maturité) du monde linux : je me demande si le fait que toutes les distributions marchent si bien et font quasiment tout ne réduit pas considérablement les tests effectués sur les distributions en pré-release. Mon idée est la suivante. Il y a 10 ans il y avait tant de petits cahots et autres anicroches sur les distros installés que madame Michu, ne se sentant plus d'aise, à chaque annonce de sortie d'une beta mandora ou susian ne pouvait se retenir de la tester sur son pentium 166MHz. De nos jours comme tout marche nickel elle attend patiemment deux ou trois versions et n'installe plus que des releases. Ce senario vous paraît-il crédible ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: Problèmes réseau

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

      Je peux comprendre qu'il soit passe a travers. Dans les differents tests que je fais, j'en avais tellement marre d'avoir a mettre une ip fixe que j'ai fini par enregistrer ma MAC directement dans mon DHCP pour me donner tout le temps la meme IP. (on parle de quelques annees). Faut tout de meme constater qu'avec le nombre de personnes qui ont un portable en lieu et place d'une machine de bureau, le DHCP l'emporte sur une IP fixe. Et meme a la maison, etant donne que la plupart des boites des fournisseurs internet utilisent egalement DHCP.
    • [^] # Re: Problèmes réseau

      Posté par  . Évalué à 2.

      Ce n'est pas un bug, mais une feature de NM...

      ... et la raison pour laquelle je ne l'utilise toujours pas, y compris sur mon portable.

      Bon, c'était censé être résolu dans sa 0.7, mais vu que c'est ce que semble embarquer cette distro, il y a de quoi en douter... dommage, le concept est pourtant sympa.
      • [^] # Re: Problèmes réseau

        Posté par  . Évalué à 3.

        > Ce n'est pas un bug, mais une feature de NM...

        C'est seulement un bug ou une fonctionnalité non encore réalisée. Il ne faut pas en faire un fromage.
        Je ne connais les détails de ce bug, mais pas de quoi s'acharner sur NM.
        Peut-être qu'avec F11 le bug sera corrigé et qu'en plus on pourra utiliser le wifi pour installer. Et là ça va être "super NM, patati et patata".

        En passant, F10 intègre pour la première fois NM dans l'installeur (et c'est la première distribution à le faire). Certes, il y aura toujours des gens qui vont dire qu'il faut faire parfait dès le début. Mais pourquoi il ne l'ont pas encore fait avec NM ?...
        • [^] # Re: Problèmes réseau

          Posté par  . Évalué à 4.

          Bah, ce n'est pas tant Fedora que je critique (encore que s'ils embarquent un NM sans IP fixe, c'est mort pour l'installation par le réseau sur le segment de LAN que j'utilise usuellement, et qui n'a strictement aucun besoin de DHCP - bon, de toute, façon, après avoir testé F9 il y a quelques mois, j'en suis venu à penser que Fedora n'est pas une distrib pour moi : même si j'aime bien la tester dans un qemulator, je ne l'installerais plus sur une machine non virtuelle) que NM.

          En fait, je trouve pour le moins incongru d'avoir développé avec le DHCP en premier, alors que l'utilisation des IP fixes me paraît un cas plus élémentaire. Si les IP fixes sont gérées, au moins, ça marche pour tout le monde - avec DHCP, bah non, faut un démon ou un relai DHCP, donc un truc en plus. Je veux bien que NM soit fait pour gérer le réseau en userland, et que ceux qui ont le plus de mal à le faire soit ceux qui utilisent DHCP, probablement même sans en avoir conscience, mais à mon avis, cet ordre de développement revient à mettre la charrue avant les bœufs.

          Du coup, je fais avec ifplugd, les pre/post-up/down, guessnet, et cie, et ça marche très bien... mais je n'ai pas de jolie GUI pour montrer la puissance de la configuration réseau aux gens.

          Après, je n'ai rien contre faciliter la configuration de Linux, via NM, ou RandR... c'est plutôt la manière de s'y prendre, en ignorant, voire en cassant, la configuration basique (merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas... d'autant que RandR et le multi-écran non cloné, ça nécessite encore la plupart du temps de rajouter une ligne "Virtual" dans le xorg.conf, donc, grandr est mignon, mais de toute façon pas adapté pour de nombreux usages).

          J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.
          • [^] # Re: Problèmes réseau

            Posté par  . Évalué à 3.

            > En fait, je trouve pour le moins incongru d'avoir développé avec le DHCP en premier, alors que l'utilisation des IP fixes me paraît un cas plus élémentaire.

            Oui et non. Avec DHCP tu n'as pas de configuration à stocker. Avec une IP fixe, il faut stocker la configuration, faire une IHM, etc.
            Enfin NM a été en premier fait pour le wifi. C'est-à-dire où DHCP est quasiment toujours utilisé. Autre aspect, NM a été fait pour être utilisé sans privilège. C-à-d qu'un non-admin doit pouvoir activer une connexion réseau. Ceci veut dire que ce n'est pas à lui de définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau) mais à un DHCP (géré par un admin qui sait ce qu'il fait).

            > merci RandR : depuis lui, plus de multi-GPU, donc plus de tri-écran... et je connais des gens qui ne se mettront pas à Linux tant que le multi-head ne marchera pas...

            Je ne connais pas ce problème. Il y a eu des régressions avec Xorg ces derniers temps. Entre autre le multiseat (plusieurs serveurs X11, plusieurs claviers/souris) ne marche plus. Il est prévu pour F12 d'y remettre de l'ordre. D'autres distributions y travaillent.

            > J'estime que c'est une manière de s'y prendre à-la-bling-bling : ça marche plus facilement, mais il ne faut pas trop gratter le vernis... j'ai vraiment du mal avec cette manière de faire.

            C'est pertinent d'une certaine manière.
            C'est seulement du développement. Au début les développeurs se consacrent au noyau (bas niveau, structure, organisation, modifications invasives) et à ce qui est le plus utilisé (pour NM : le wifi et donc dhcp). Puis ils font les finitions (multi-GPU, multi-seat, etc).
            Ça serait formidable de tout faire complètement dès le début. Mais ce n'est pas toujours possible. Les développements doivent avancer. Contrairement à Windows, ils se font à la vue de tous (via Fedora ou autre). Linux a encore beaucoup de retard dans certains domaines (NM fait bouger les choses dans le bon sens) et notamment pour Xorg (il n'y a que depuis peu de temps qu'on a le branchement à chaud d'écran par exemple, alors que Windows a ça depuis des lustres et que c'est hyper indispensable sur un portable en entreprise).

            Les développeurs ne se disent pas : "et si on ignorait ceux qui veulent des IP statiques". Ils font au mieux pour le long terme et avec des moyens ridicules par rapport à Windows.
            Ce que tu critiques ici, c'est seulement le manque de moyen en développement de Linux.

            Le développement du logiciel libre n'est pas un long fleuve tranquille. Des fois ça casse de partout, mais il faut faire avancer le logiciel libre. Ce n'est pas avec l'attitude "surtout pas de régression" qu'on va y arriver. Si une évolution importante demande des régressions temporaires, il faut le faire, et ne pas attendre le 36 du mois. Il doit être de l'honneur des utilisateurs du logiciel libre (et notamment des utilisateurs de Fedora) de le comprendre.
            • [^] # Re: Problèmes réseau

              Posté par  . Évalué à 5.

              > Avec DHCP tu n'as pas de configuration à stocker. Avec une IP fixe, il faut stocker la configuration, faire une IHM, etc.

              Sauf que comme tu le dis, NM a été fait pour le wifi en premier... or, pour le wifi, il faut stocker de la clé... donc, de quoi faire du stockage, c'est déjà là.

              Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.



              > définir une adresse IP (trop dangereux ; problème de sécurité ; ça peut foutre le border sur le réseau)

              Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point. Si ce que tu sous-entends est un réseau où le DHCP et les IP fixes peuvent être sur un même switch ou VLAN, et où on peut spécifier une adresse IP qui soit dans l'étendue du DHCP, là, c'est du travail de cochon, et c'est de toute façon du ressort de l'admin.

              Maintenant, je comprends bien la démarche : simplifier les cas pour les utilisateurs qui ne s'y connaissent pas. Comme je l'ai dit, c'est quelque chose que je trouve très bien (quand ça marche : cette fin d'année dernière, j'ai installé une Lenny à un pote qui voulait voir - NM était incapable de choper un bail DHCP ; ça a très bien marché à la mimine dans /etc/network/interfaces ; j'ai renoncé à chercher à comprendre)...

              Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.



              > Il y a eu des régressions avec Xorg ces derniers temps

              Ces dernières années, même. Ça fera deux ans le mois prochain que X.org 7.2 est sorti, et empêche de faire du multi-GPU (donc, du tri-écran) et du multi-serveurs X (de première utilité quand on veut dévouer un écran à l'affichage de videos, par exemple)... entre autres.

              Les GPU objects sont censés résoudre le premier problème... ils sont annoncés tous les 6 mois... mais tout aussi souvent repoussés. Et j'imagine qu'on ne verra pas le retour de cette chose indispensable dans, par exemple, le graphisme ou la finance, avant encore des années. Je n'appelle plus ça avancer - pour note, les OS redmondiens savent aussi gérer ça depuis des éons...

              Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd : résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.

              D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas sans peine pour les utilisateurs qui ne connaissent pas l'édition manuelle des fichiers de conf, en dehors du mode clone, puisqu'il faut toujours rajouter un Virtual dans le xorg.conf pour le mode étendu.

              Résultat : au bout de deux ans, tout est devenu galère pour tout le monde, sauf ceux qui utilisent le mode clone (euh... même en présentation, il y a des gens qui utilisent le mode clone ?)...

              Pour le problème du multi-serveurs X et des galères de focus et cie, j'ai pu lire sur les mailing-lists de développement que ce devait être le boulot des environnements graphiques... j'aime autant ne même pas dire ce que je pense de cette impérieuse suggestion :|

              Ce que je critique, ce n'est pas quelques régressions temporaires, mais des régressions très très longues, non fructueuses, et plus généralement, une démarche qui me semble consister à partir de cas trop particuliers, pour casser tous ceux qui le sont un peu moins. De mon point de vue d'utilisateur, qui n'en respecte pas moins le temps passé à développer, dussé-je le préciser, les problèmes ne sont ni pris dans le bon ordre, ni de la bonne manière... et _fait_ est que je ne m'en réjouis plus.

              La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.
              • [^] # Re: Problèmes réseau

                Posté par  . Évalué à 1.

                > Sauf que comme tu le dis, NM a été fait pour le wifi en premier... or, pour le wifi, il faut stocker de la clé... donc, de quoi faire du stockage, c'est déjà là.

                Et où tu veux en venir ?
                Que les développeurs sont des guignols ?
                Je ne sais pas exactement le pourquoi du comment du bug de NM dans l'installeur de Fedora (et toi non plus), mais comme Fedora est principalement dédié aux contributeurs, que Fedora sort tous les 6 mois, il ne faut pas être devin pour comprendre que ce bug est très très très probablement lié à un problème technique ou par manque de moyen (temps ou développeur).

                > Quant aux IHM, ce n'est pas du ressort de NM, mais des surcouches graphiques à NM... NM n'a pas besoin de clickouille pour fonctionner.

                Tout ceci est mignon, mais l'installeur de Fedora est texte et graphique. Que ça ne soit pas fait directement dans NM, n'empêche pas qu'il faut une IHM. Et si tu vas par là, je suis sûr qu'à coup de "vi" et "echo bidule > machin" tu peux fixer l'adresse IP avec NM lors de l'installation de Fedora. Tu peux aussi te passer d'installeur et faire des "mke2fs ... ; ifconfig ... ; route ; yum --installroot=... ; etc". Alors, tu ne veux toujours pas d'IHM ?

                > Hein ? ... si on spécifie une adresse IP qui n'est pas sur le bon segment, bah, ça ne marche pas : point

                Ben tu ne connais pas grand chose en réseau... Et je ne suis pas une pointure...
                Et le cas ou l'utilisateur prend une adresse IP déjà utilisée, tu y penses ? C'est juste un exemple. Les IP fixes c'est seulement pour quelques bécanes bien sélectionnée et quasiment que des serveurs.
                De plus, avec DHCP on peut aussi fournir des IP fixe à des bécanes (soit avec l'adresse MAC, soit avec le nom de la bécane).

                > Sauf que faire ça en gérant des cas très particuliers, en négligeant de gérer les cas les plus simples, juste pour se grouiller d'avoir un truc qui marchouille à-la-rache, j'estime que c'est faire les choses dans le mauvais ordre. Point.

                Ben prends une RHEL/Centos. Point.
                Tu te trompes de distribution. Point.
                En passant, RHEL/Centos c'est Fedora. Point.
                RHEL/Centos ce n'est pas une autre distribution, c'est un fork de Fedora avec d'autres objectifs. Donc ce n'est pas le modèle de développement de RHEL contre celui de Fedora, c'est Fedora avec RHEL. Une RHEL sort tous les 2 ans (et maintenant ça va passer à tous les 3 ans), donc une RHEL peut sortir avec 2 ou 3 mois de retard pour éviter qu'il manque bidule ou pour corriger le bug machin. Ça a très peu d'incidence sur RHEL. Par contre, pour Fedora c'est presque catastrophique (ce sont des contributeurs qui glandent durant 3 mois sur une sortie de distribution qui est prévue tous les 6 mois !).

                > Un cassage de 6 mois, bon, m'en fous, à la limite... mais deux, trois (au strict minimum, tel que c'est parti), quatre ans, ça commence à être lourd

                Et ?
                Tu crois que les développeurs en sont contents ?
                Tu ne crois pas qu'ils ont des priorités. Que supporter le branchement à chaud (d'écran, de clavier, de souris (et tout ceci marche)) est beaucoup beaucoup beaucoup plus important que de s'occuper du geek qui s'astique le manche avec son tri-écran ?

                > résultat, avant, j'installais le GIT de X.org et je bugreportais beaucoup... maintenant, je ne le fais plus du tout, et je suis à la limite de m'en foutre.

                Un de perdu, dix de retrouvé.

                > D'autant que m'est avis que le branchage à chaud ne fonctionne toujours pas

                Il marche chez moi. En passant, ce n'est pas Xorg 7.2, c'est Xorg 7.4 que j'utilise. Xorg 7.2 est sorti il y a 2 ans il me semble...


                > pour casser tous ceux qui le sont un peu moins.

                T'es sérieux ?
                Tu crois qu'il y a beaucoup de personnes qui utilisent 3 écrans ou 2 cartes graphiques à la fois ?
                Franchement...

                > les problèmes ne sont ni pris dans le bon ordre

                C'est-à-dire ?
                Il ne fallait pas faire le support de branchement à chaud ? Il fallait en premier s'occuper des 0,01 % d'utilisateurs qui ont 2 cartes graphiques et 3 écrans ?

                > ni de la bonne manière...

                Je n'ai pas les compétences pour en juger, je doutes que tu les aies aussi...

                > La philosophie UNIX a toujours été de partir sur des choses simples, avec des outils simples, qui faisaient bien leur travail. Et _fait_ est qu'on s'en éloigne (au bas mot) aujourd'hui... et ça non plus, je ne m'en réjouis pas.

                Ben prend une vieille distribution...
                Aujourd'hui le défi du logiciel libre n'est pas de faire l'Unix à papa (qui configure tout nickel à coup de vim. NB : j'en ai fait parti !), mais de faire un OS simple.
                Je suis sûr que t'es super content que l'USB marche nickel (ou presque) sous Linux sans que tu aies à configurer quoique ce soit. Ben l'USB sous Linux, pour les développeurs, a été un enfer à réaliser. Le Xorg qui rivalisera avec Windows est un enfer a réaliser. Mais quand il sera là (et il faut y venir !) tu ne pourras plus t'en passer comme tu ne peux plus te passer d'USB qui marche les doigts dans les nez (ce qui n'a pas été le cas durant de nombreuses années...).

                Faire simple c'est bien. Mais ce n'est pas toujours possible car les défis, et surtout ceux à venir, sont compliqués. Mais si tu as des solutions simples pour ces problèmes compliqués, n'hésites pas, les développeurs te baisseront les pieds.
                • [^] # Re: Problèmes réseau

                  Posté par  . Évalué à 3.


                  Et le cas ou l'utilisateur prend une adresse IP déjà utilisée, tu y penses ?


                  Et ça fait un problème de sécurité ? je vois pas la...
                  L'IP spoofing, c'est un peu plus complexe...
                  • [^] # Re: Problèmes réseau

                    Posté par  . Évalué à 2.

                    Ben, tu n'usurpes pas complètement l'ip de l'autre, mais tu peux quand même foutre un peu la pagaille dans le réseau, il y a désormais 2 adresses MAC pour une seule IP et pas de bol, si tu envoies tes paquets un coup d'un côté, un coup de l'autre ... tu perturbes le réseau.

                    Dans ce sens, c'est un problème qui peut rendre un serveur "inaccessible"
                    • [^] # Re: Problèmes réseau

                      Posté par  . Évalué à 2.

                      Oui, enfin, si tu mets un serveur ou quoi que ce soit de critique sur le même sous-réseau que tes invités, tu cherches le bâton pour te faire battre...

                      ... ça revient à ce que je disais quand je parlais de travail de cochon ; et ça, ça incombe à l'admin.



                      Si tu alloues un sous-réseau pour les machines dont tu n'es pas maître, n'importe qui pourra s'y configurer l'adresse de quelque serveur que ce soit en dehors de ce sous-réseau, ça coincera au niveau d'un routeur entre ce sous-réseau et tes autres, et il n'arrivera pas à avoir une connexion IP qui-va-bien.

                      Au pire, l'emmerdeur pourra prendre une adresse déjà allouée à un autre invité, et "perturber" le sous-réseau que tu leur aura alloué... le reste du réseau ira très bien quand même. Après, si les invités qui se font emmerder utilisent des services mal sécurisés pour faire des choses confidentielles, qui plus est sur un réseau auquel ils n'ont aucune raison de faire confiance, et que des informations à eux fuient, ça leur fera la bite, et leur fera prendre de bonnes habitudes...

                      Quant au cas où le sous-réseau est utilisé par de multiples personnes, que les machines sont maîtrisées, et qu'on craint qu'un glandu se serve de NM pour s'allouer une IP fixe et foutre la merde... bah, les machines étant maîtrisées, on n'installe pas NM, et il faut alors être root pour toucher à la conf réseau de la machine... et hop.



                      N'en reste pas moins qu'en tout point de cette situation, le problème de sécurité est humain (admin ou invités)... mais avec NM ou pas pour gérer les IP fixes, les emmerdeurs pourront quand même s'en configurer une s'ils se ramènent avec leur machine (et dans le cas contraire, ce n'est pas aux utilisateurs de toucher à la conf IP - aussi, quelque chose qui le leur permet n'a rien à y foutre) ; ce qui n'est pas un problème si le réseau est conçu proprement.
                      • [^] # Re: Problèmes réseau

                        Posté par  . Évalué à 2.

                        On est d'accord, mais ce que tu appelles un sous-réseau, je l'appelle plutôt un réseau... à par ça, on est d'accord
                        • [^] # Re: Problèmes réseau

                          Posté par  . Évalué à 2.

                          C'était pour bien marquer la différence entre le réseau du site (quoi que soit le site... parce que si on commence à ergoter là-dessus aussi :p), et les subdivisions (pas forcément d'un même espace IP autre que 0.0.0.0/0, en IPv4, certes) qui en seront faites ;)
    • [^] # Re: Problèmes

      Posté par  . Évalué à 1.

      J'utilise surtout Windows, mais ça fait environ 4-5 ans que j'installe diverses distributions Linux en multi-boot.

      Ce que je constate, depuis deux ans, c'est que c'est plus simple, mais de moins en moins stable, notamment le processus d'installation des logiciels/paquets.
      Exemple: je demande l'installation d'un ou plusieurs paquets
      > ça plante/crash/bloque sur l'un d'eux
      > merde, tout le système d'installation est bloqué
      > merde, les outils censés désinstaller/débloquer ne fonctionnent pas
      > merde, Linux plante au redémarrage
      (et sur l'une des distributions (Ubuntu 7.10, je crois), il fallait plusieurs minutes pour lancer n'importe quelle application! même si celle-ci fonctionnait ensuite à vitesse normale, parce que le gestionnaire de paquets cassait les couilles à chaque lancement!)
      En général, seul un formatage permet de remettre les choses à plat (je crois n'avoir réussi qu'une seule fois à résoudre ces problèmes d'installation.)

      Ça fait un moment qu'aucune distribution n'est capable de m'informer de façon fiable sur la résolution actuelle de mon écran.
      > KDE dit une chose
      > le système de la distribution me dit autre chose
      > le driver de ma carte m'informe d'une troisième chose
      En général, le système n'est jamais foutu de retenir la configuration que je donne, sauf si je vais bidouiller dans xorg.conf (et je ne suis même plus sûr que ça marche toujours).

      Amha, le monde Linux souffre de son hétérogénéité. Chaque distribution suit son modèle, bien sûr pas compatible avec les autres. On a le sentiment d'une perte de temps considérable que chaque distributeur passe à adapter les paquets à son système, et on se demande bien pourquoi.

      Sur mon PC acheté en novembre, aucune distribution Linux ne parvient à se lancer correctement, sauf la dernière openSUSE, quelque chose fait planter le serveur X. Il y a aussi Debian qui se lance mais affiche une résolution tellement merdique que j'ai peur pour mon écran. :/
      • [^] # Re: Problèmes

        Posté par  . Évalué à 2.

        Fedora n'est pas faite pour être stable. Elle est là pour innover, pour être à la pointe de la technologie. C'est la bêta de la future mouture de l'OS pro de RH.

        Si tu veux quelque chose de très stable, libre et gratuit, y'a centOS qui utilise les sources de Red Hat Linux Entreprise. Et CentOS est dédiée aux utilisateurs... elle! http://fr.centos.org/

        (Après si tu t'amuses à installer des drivers proprios bêta et des paquets Debian Sid sur ton Ubuntu, viens pas de plaindre de l'instabilité)
    • [^] # Re: Problèmes réseau

      Posté par  . Évalué à 1.

      Euh je ne suis pas sûr de bien comprendre !

      Je suis sur mon réseau privé en Wifi WPA avec IP fixe.
      J'ai pu spécifier mon IP, masque de sous réseau, passerelle, DNS ... sans DHCP, sans problème et avec Network Manager !

      Tu as bien regardé comment marche NM ?

      J'en rajoute une couche avec l'annonce de Network Manager 0.7 (par le développeur lui même) :
      http://blogs.gnome.org/dcbw/2007/10/15/networkmanager-07-is-(...)

      Through static IP support (including multiple IP addresses), you could use NM on your server or stationary desktop machine if you wish. You don’t need to use DHCP.
      • [^] # Re: Problèmes réseau

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

        Apparemment il y un petit problème de terminologie : en utilsant le « nom commun » network manager, Je parlais seulement de la petite interface graphique qui se lance en cliquant dans system/administration/network et qui apparemment partage son backend avec le configurateur de réseau qui est utilisé en mode texte lors de l'installation ; absolument pas du programme appelé par le doux nom propre networkManager... Et mon intention n'était en aucun cas de lancer un troll, même si le vendredi n'était pas bien loin. Désolé.

        Pour répondre, oui je suis certain du problème. D'ailleurs après l'avoir contourné chez moi j'ai un peu cherché pour voir si d'autre avait rencontré la même chose et s'il fallait que je soumette un rapport de bug et j'ai trouvé des dizaines d'occurences d'exactement le même problème réglé précisément de la même manière. C'est juste une grossière erreur dans un script ou une valeur est écrasée par une autre. Si je me souviens bien il s'agit d'une broutille tel que remplacement de l'adresse du gateway par celle de la machine ou quelque chose de similaire.

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # KDE 3.5.10 ?

    Posté par  . Évalué à 1.

    Je croyais que depuis Fedora 9, KDE 3.5 n'était plus fourni. La Release Notes semble indiquer la même chose :
    http://docs.fedoraproject.org/release-notes/f10/fr/What_is_t(...)

    Où as-tu vu que l'on pouvait installer KDE 3.5.10 sur la Fedora 10 ?
    • [^] # Re: KDE 3.5.10 ?

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

      Y'a une réponse là : http://docs.fedoraproject.org/release-notes/f10/en_US/What_i(...)

      Donc une partie des paquets sont disponibles mais pas tout. Chapeau bas a Mandriva pour avoir laissé l'intégralité de KDE 3.5 disponible.

      Steph
      • [^] # Re: KDE 3.5.10 ?

        Posté par  . Évalué à 0.

        > Chapeau bas a Mandriva pour avoir laissé l'intégralité de KDE 3.5 disponible.

        Ce n'est pas pareil. Fedora a fait de KDE 4 son bureau KDE. Mandriva fait de KDE 3 son bureau KDE. Sous Fedora tu as l'intégralité de KDE 4 par défaut, sous Mandriva c'est KDE 3.
        • [^] # Re: KDE 3.5.10 ?

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

          Non, Mandriva a fait de KDE4 son bureau par défaut depuis la 2008.1, tu as la possibilité néanmoins d'installer KDE 3.5 depuis les dépôts (dans sa quasi-intégralité).
    • [^] # Re: KDE 3.5.10 ?

      Posté par  . Évalué à 3.

      De ce que je sais (NB: je n'utilise pas KDE) on peut installer des applications KDE 3 sur Fedora, mais il n'y a que KDE 4 pour le bureau (depuis F8).

Suivre le flux des commentaires

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