Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Journal : La fedora 8 est pas mal.

Posté par fleny68 () le 03 mars 2008
Je me suis décidé, parce qu'on n'est jamais si bien servi que par soi-même, à installer une fedora. fedora 8. PPC. Je précise bien PPC, Comme ça ceux qui vont me dire: chezmoiçamarchemieuxqueça, je répèterai PPC.

J'ai découvert à cette occasion que Fedora proposait aussi (comme ubuntu) d'offrir les CD. Une bonne idée. On devrait centraliser, faire une sorte d'ikarios qui engrange les dons et envoie le CD de la distribution au choix.

ça fait bien 10 ans que j'ai pas vraiment touché une RedHat ou assimilé. Mais ma deuxième distribution a été une RedHat 4 ou 4.2, une boite bleu avec le chapeau rouge, qui utilisait fvwm95 et un gestionnaire d'admin en tcl/tk. Je crois. Ma première distribution a été une slackware, ça n'étonnera personne. Depuis Bo mes ordis sont sous Debian. Un 486DX2 66MHz de 1994 à 2002, le power mac biG4 866MHz depuis 2002.

Je précise que je n'ai pas l'intention de quitter debian. J'ai un deuxième disque dur, il a eu une ubuntu qui a failli devenir ma distribution principale, jusqu'à ce que l'arrêt anoncé du support ppc par ubuntu me refasse changer le boot de l'openfirmware. Fedora j'en ai besoin pour tester des rpm.

Fedora au premier abord, c'est net, propre et bien foutu. On peut chipoter, mais l'installation se passe agréablement, tout graphique, sauf la quetion pour si on veut tester le media qui est en ncurses rouge et bleu, là ça fait pas propre, mais sinon c'est graphique/X et les questions sont claires, les choix par défaut cohérents. La carte zoomable pour choisir le fuseau horaire d'un clic, c'est du plein-les-yeux qui sert à rien, d'accord, mais quand même ça marque. Après ça on aura probalement droit à une installation sous compilz. Ça va être trop bien comme dirait ma fille qui veut jouer avec tuxpaint.

Quand je pense au mal que j'ai eu à paramétrer mon écran 15"flat sous Xfree il y a cinq ans. Là c'est tout automatique dès le début de l'installation. A force de s'habituer on mesure pas les progrès.

Lors de l'installation une seule question un peu technique. dhcp ou pas? Nom de machine par dhcp ou pas? Moi je sais. oui et non. Mais la question fait plus technique que les autres. Sinon les choix par défaut sont bien.

Sérieux. Une sécurité bien affichée (paramétrage du pare-feu et de SELinux que j'ai pas encore testé sous ma debian), ça fait très sérieux. Partitionnement en LVM, automatisé avec plusieurs choix. Bien. Noyau smp, automatiquement installé. Parfait.

Un seul problème, mais de taille: le clavier apple usb de mon mac n'est pas dans la liste. D'ailleurs, même après l'installation je n'arrive pas à le faire reconnaitre à gnome. C'est pour dire.

Un autre problème, mineur: la carte son (powermac) n'est pas reconnue. De toute façon la machine est bruyante, j'ai un casque usb. Un dernier truc, il me semble que le réglage des ventilos ne se fait pas: ma debian fait moins de bruit. Quelques réglage à affiner, probablement. Rien de grave.

L'installation par défaut est du genre américain moyen: un peu obèse. Gnome, Firefox, Evolution (et pas Thunderbird), OpenOffice doit y être (j'ai pas vérifié) Latex y est (mais pas texmaker je crois), et un tas d'autre trucs: 3,8 GigaOctets, ma première RedHat tenait largement dans 170 MO. fvwm95 c'était bien. Gnome c'est lourd. J'aime plus, mais j'ai pas encore trouvé ce qui allait le remplacer chez moi. 3,8 GO d'occupés, et y'a même pas emacs. Vim oui.

Fedora préfère Gnome à Kde, Vim à Emacs, et RPM à Deb.

Après une heure d'utilisation je suis perplexe. Une mise à jour qui dure une plombe, et pendant laquelle la fenêtre du gestionnaire peine à se redessiner. Pendant la mise jour SELinux m'envoie une quinzaine d'alerte de blocage de cron à cause de smolt, jusqu'à ce que SELinux m'informe qu'il redémarre. Bizarre. La fenêtre de mise à jour ne donne pas d'info sur le temps restant, ça manque.

Smolt m'apprend que les ppciste sont même pas 1%, mais quand même plus que les i386ards. Il y a 25 sparc64 dans le tableau.

Redémarrage: fenêtre graphique avec possibilité d'afficher le boot, c'est très beau. Par contre à l'extinction on n'a droit qu'au mode terminal, c'est dommage. de pas éteindre sur un joli coucher de soleil en graphique.

Le gestionnaire de paquets me rappelle synaptic, il met une plombe à répondre aux recherches. En ligne de commande il y a yum, autant dire un truc chinois. Je suis sous debian depuis Bo. Putain 10 ans! man yum. Gcompris est là. Java non. Il faut dire que java en ppc, c'est celui d'ibm. Je vais devoir le mettre à la main. Ça tombe bien il est fourni en rpm. (Pour les debianeux il y a java-package qui s'occupe de le repackager.)

La première fois que j'ai vu une installation graphique aussi bien léchée, c'était Mandrake, avec son retailleur de partition intégré. Puis Suse dont j'ai vu tourner l'installation deux ou trois fois. J'ai longtemps conseillé Mandrake. parce qu'en France il y a(vait) pas mal d'utilisateurs. Pour cette raison je conseille ubuntu. Y'a du monde chez ubuntu.

Et Fedora, combien de divisions? Y'a des forums francophone? Y'en a. Le prochain qui me demande quelle linux, je l'envoie chez fedora. Pour varier un peu. Et faire redescendre l'ego des ubuntards. Fedora c'est tès bien aussi.

> Lire le journal (39 commentaires, moyenne: 2,1).  

Vous avez demandé le commentaire #909935.

Re:

Posté par IsNotGood () le 03/03/2008 à 04:01. (lien). Évalué à 1.

> tout graphique, sauf la quetion pour si on veut tester le media qui est en ncurses rouge et bleu

Parce que le test est fait avec ce qu'il y a dans initrd (le mini-minimum). Passer initrd, c'est "stage2" avec l'interface graphique, etc...
Le test doit être fait le plus tôt possible et avec le moins possible. Il serait bête que ça plante à cause d'un mauvais CD avant que tu arrives au test du CD.

> La carte zoomable pour choisir le fuseau horaire d'un clic, c'est du plein-les-yeux qui sert à rien

Pour la carte ce n'est pas du "plein-les-yeux qui sert à rien". M'enfin, si tu préfères une liste de 3 km.

> Après ça on aura probalement droit à une installation sous compilz.

L'interface graphique est disponible pour Red Hat depuis RH 6.0 !!!!
A l'époque ça utilisait framebuffer (et était activé pour assez peu de carte graphique).
Au niveau look très peu de chose ont changée et le fonctionnement global reste le même.
Toi ça t'impression, mais un mec qui a utilisé une vieille Red Hat ne sera pas impression.
Ce n'est vraiment pas un domaine où Fedora est très actif. Compare avec une FC3, et c'est le jeux des 7 erreurs.

> OpenOffice doit y être (j'ai pas vérifié)

Par défaut il est installé.

> Latex y est (mais pas texmaker je crois)

texmaker n'est peut-être pas installé par défaut. Mais il est dispo.

> Une mise à jour qui dure une plombe

Parce que F8 est sorti il y a "longtemps" et que les mises à jour se sont accumulées.
Fedora ne fait pas que des mises à jours de sécurité ou de gros bug comme Debian ou Ubuntu le fait :
http://blog.kagesenshi.org/2008/03/keep-fedora-less-moving-u(...)
Pour info il y a plus de 4,5 Go (!) de src.rpm en mise à jours.
F8 est sorti avec Linux 2.6.22. Il y a maintenant le 2.6.23. Le 2.6.24 est en préparation. KDE 3.5.9 est dans testing et ne va pas tarder a arriver en mise à jour.
La politique de mise à jour n'est pas la même que Debian/Ubuntu.

> c'est dommage. de pas éteindre sur un joli coucher de soleil en graphique.

C'est un reproche qui existe depuis... FC1 ou FC2. Il semble que personne est motivé pour s'occuper de ça.

> Gcompris est là. Java non.

Il y a IcedTea sur i386 et x86_64 pour F8. La version PPC n'a pas été prête à temps. IcedTea pour ppc est dans Rawhide. Il doit y avoir java mais avec gcj (qui n'est pas au niveau de IcedTea).

> J'ai longtemps conseillé
> je conseille
> je l'envoie chez

Faites comme moi. Dites qu'il y a plein de distributions. Que globalement Ubuntu/Suse/Mandriva/Fedora sont adaptées à un nouveau. J'ajoutes seulement que s'il prend une Fedora, vu que j'ai une Fedora, je pourrais plus facilement l'aider.

En passant, il y a XFCE sous F8 puisque que tu trouves que Gnome est "lourd" (en combien de secondes tu te loggues sous Gnome ou sous KDE ?).
Pour XFCE => yum groupinstall XFCE

  • [^]Re: Re:

    Posté par fleny68 () le 03/03/2008 à 13:13. (lien). Évalué à 2.

    En parlant de plantage à cause d'un mauvais dvd, j'ai eu la cas. pour plantage pour le paquet liberations-fonts, qu'on n'imagine pas bloquant..

    Sinon pour les mises à jour le problème n'est pas la taille. Le problème c'est la fenetre qui laisse penser que le truc est bloqué: pas de rafraichissemet. Et aucune info sur le temps restant...

    Sinon, rien à dire, c'est très propre, carré, ça a l'air bien fait.

    • [^]Re: Re:

      Posté par fleny68 () le 03/03/2008 à 21:02. (lien). Évalué à 2.

      La mise à jour qui plante, par contre ça fait pas propre. Des conflits entre les paquets. Bizarre.

      • [^]Re: Re:

        Posté par IsNotGood () le 03/03/2008 à 21:42. (lien). Évalué à 3.

        C'est dans une certaine mesure "normal".
        Yum (en fait la politique Fedora de mise à jour) n'ignore pas les paquets qui posent problèmes. S'il y a une mise à jour, elle doit être appliqué. Si ce n'est pas possible, c'est un bug. Jamais yum, dans sa configuration par défaut, ne "cachera" ça. Avec apt, des mises à jours peuvent être ignorées. Fedora se le refuse (du moins dans la configuration par défaut, il y a un plugin pour avoir le comportenant de apt).

        > Des conflits entre les paquets.

        99 fois sur 100, c'est la cause de mirroirs qui ne sont pas à jour. Il faut faire un essai plus tard.

        • [^]Re: Re:

          Posté par rewind () le 03/03/2008 à 22:54. (lien). Évalué à 4.

          > Avec apt, des mises à jours peuvent être ignorées.

          Les mises à jours ignorées ne compromettent pas l'intégrité du système. C'est souvent qu'un paquet a été compilé pour une architecture mais pas pour une autre et toutes les paquets qui en dépendent sont mis en attente parce qu'ils ne peuvent pas passer à la version suivante. C'est souvent réglé dans la journée qui suit.

          Un deuxième cas est quand il faut installer des paquets supplémentaires (différence entre upgrade et dist-upgrade). Dans le cas d'un upgrade, il faut un paquet qui ne peut pas être installé (alors qu'il le serait avec un dist-upgrade) donc les paquets qui en dépendent sont mis en attente. Là, c'est au choix de l'utilisateur.

          Apt ne cache rien du tout, il dit tout aussi hein. Il pose la question à chaque fois et libre à l'utilisateur averti de savoir ce qu'il fait.

          • [^]Re: Re:

            Posté par IsNotGood () le 03/03/2008 à 23:12. (lien). Évalué à 2.

            > Les mises à jours ignorées ne compromettent pas l'intégrité du système.

            Ça dépend. Si c'est une mise à jour de sécurité alors c'est oui.

            Je n'ai pas envis de pourrir apt. Mais il faut comprendre les choix de chaqu'un.

            Quand yum dit "Error impossible de mettre à jour", ça ne veut pas dire que Yum a planté. Ses "erreurs" arrivent 99,99999 fois sur 100 _avant_ que la mise à jour réelle commence. Elles arrivent lors des vérifications. La vérification est faite en deux passent. La première avec assez peu d'information (afin d'éviter des tonnes de download). Après la première vérification, il y a demande de confirmation à l'utilisateur. La seconde est faite avec toutes les informations disponibles puisque après que tous les paquets nécessaire aient été downloadé. Elle est réalisé en faison une transaction "à blanc" sur la base rpm (en utilisant librpm comme rpm utilise librpm) et en utilisant les entêtes des paquets rpm. Après vérification tout doit marcher. Si ce n'est pas le cas, c'est définitivement un bug.
            Ceci est assez lourd mais offre une excellente fiabilité.

            • [^]Re: Re:

              Posté par Sufflope (Jabber id, page perso, ) le 03/03/2008 à 23:48. (lien). Évalué à 4.

              Euh, rpm a besoin d'infos contenus dans les paquets rpm directement, pour calculer les dépendances (et sux) ??
              Ou alors j'ai rien compris à tes explications nébuleuses.
              Avec apt, quand tu as mis à jour tes dépôts, soit la MAJ passe (que des MAJs) soit elle nécessite un dist-upgrade (ajout/suppression de paquets), pas besoin de X passes et une partie du paquet pour calculer l'arbre des dépendances.
              Et si une MAJ de paquet fouare (ça arrive, mais tellement peu souvent) c'est quasiment toujours parce que t'as fait une belle merde à la main (ou alors c'est de la MAJ entre versions testing différentes avec un peu d'unstable pour donner du goût et t'as oublié de faire le petit truc nécessaire pour résoudre le merdier que t'as décidé de foutre dans ton système (testé et approuvé))

              • [^]Re: Re:

                Posté par IsNotGood () le 04/03/2008 à 02:07. (lien). Évalué à 2.

                Introduction : ce n'est pas car rpm ne fait pas comme deb, que rpm fait mal.

                > Euh, rpm a besoin d'infos contenus dans les paquets rpm directement, pour calculer les dépendances (et sux) ??

                Oui et non. Les derniers versions de yum reconstruisent les entêtes avec les infos sur les dépôts. Puis c'est envoyé à librpm pour finaliser les dépendances (c'est la phase "Running transaction check").

                > Avec apt, quand tu as mis à jour tes dépôts, soit la MAJ passe (que des MAJs) soit elle nécessite un dist-upgrade (ajout/suppression de paquets)

                Cette notion d'update et d'upgrade n'existe plus dans yum. Elle a existé à une époque lointaine.

                > pas besoin de X passes

                C'est fait en interne à yum. Va savoir combien de passe fait apt sans que tu le saches...

                > et une partie du paquet pour calculer l'arbre des dépendances.

                Les entêtes des paquets (reconstruit depuis les dernières versions de yum ; avec librpm) sont utiliser pour simuler une transaction. Yum l'affiche avec un message du type "running test transaction". Ce contrôle permet de vérifier par rapport à ce qui est installé (afin d'éviter que le nouveau paquet toto écrase un fichier du paquet titi déjà installé par exemple (alors que titi n'est sur aucun dépôt)). Je crois que c'est aussi utilisé pour évaluer l'ordre d'installation. Des paquets ont des dépendances à l'installation uniquement. Toto peut demander titi pour être installé, mais n'a pas forcément besoin de titi pour fonctionner. Titi doit être installé avant toto.

                • [^]Re: Re:

                  Posté par IsNotGood () le 04/03/2008 à 02:31. (lien). Évalué à 4.

                  > Cette notion d'update et d'upgrade n'existe plus dans yum.

                  Si ça existe. Mais ce n'est plus utilisé par Fedora.
                  $ man yum
                  upgrade

                  Is the same as the update command with the --obsoletes flag set. See update for more details.

                  update

                  ...
                  If the --obsoletes flag is present yum will include package obsoletes in its calculations - this makes it better for distro-version changes, for example: upgrading from somelinux 8.0 to somelinux 9.


                  yum.conf par défaut dans Fedora :
                  obsoletes=1

                  Option aussi activé par défaut dans yum upstream.




                  Trollons à la apt fanboys : Mon Dieux que c'est compliqué apt, il y a update et upgrade... Yum n'a pas de yum-cache : http://www.ccl.net/cca/software/UNIX/updating-redhat/apt-how(...)
                  13 options !
                  Mon Dieux que c'est compliqué apt...
                  Fin troll.

                  [^]Re: Re:

                  Posté par rewind () le 04/03/2008 à 09:53. (lien). Évalué à 3.

                  Franchement, t'as pas peur du FUD toi...

                  > Va savoir combien de passe fait apt sans que tu le saches...

                  Ho les méchants, ils nous cachent des passes, saimal toussa. Franchement, tu regardes les sources et tu le sais... Et même sans regarder les sources, je peux te le dire. S'il y a un update et un upgrade, c'est qu'il y a une raison, ils n'ont pas la même utilité et on ne les invoque pas nécessairement toujours l'un à la suite de l'autre. update, c'est pour mettre à jour la liste des paquets avec leurs metadonnées (dépendances toussa). Ça sert à connaître la liste des paquets qui sont sur le dépôt, histoire de ne pas se baser sur une vieille liste plus à jour. Ça tu peux le faire aussi souvent que tu veux. Mais les moments les plus judicieux, c'est juste avant une installation d'un nouveau logiciel (apt-get install) et juste avant une mise à jour globale (apt-get [dist-]upgrade). Ça évite d'avoir plusieurs passes avec des morceaux téléchargés, d'autres recalculés on ne sait trop comment. Dans le cas d'APT, on a toute l'information nécessaire au bon moment et on sait ce qu'on fait.

                  [^]Re: Re:

                  Posté par Spyhawk () le 04/03/2008 à 12:57. (lien). Évalué à 3.

                  >>Euh, rpm a besoin d'infos contenus dans les paquets rpm directement, pour calculer les dépendances (et sux) ??
                  >>Ou alors j'ai rien compris à tes explications nébuleuses.

                  >Introduction : ce n'est pas car rpm ne fait pas comme deb, que rpm fait mal.

                  Heu, perso je comprends pas non plus ce qui se passe avec YUM (que je ne connais pas, ou très peu).

                  Les autres systèmes RPM (opensuse, mandriva, ..), à ma connaissance, fonctionnent exactement de la même façon qu'apt :
                  - téléchargement des métadonnées (rafraichissement)
                  - résolution des dépendances, sélection des paquets à installer
                  - téléchargement et applications des patchs/logiciels.

                  D'ailleurs, on entend souvent que "deb c'est mieux que rpm", alors que tout le monde sait qu'ils sont plus ou moins similaires, de telle sorte qu'aucun n'a supplanté l'autre.

                  La différence réside dans le méta-packager utilisé : Là où le monde .deb n'en a qu'un (apt, avec éventuellement un front end), .rpm en a plusieurs (yum, urpm, yast/zypp, ..).

                  On devrait donc dire : "apt c'est mieux que yum/urpm/yast". Mais je ne suis pas convaincu que .deb est mieux que .rpm.

                  --
                  "I wonder where I'll go now. The net is vast and infinite."
                  • [^]Re: Re:

                    Posté par rewind () le 04/03/2008 à 13:23. (lien). Évalué à 1.

                    sans vouloir relancer le troll, je dirais que si rpm a autant de gestionnaire (urpm/yast/yum), c'est un corrollaire du fait que rpm fut moins bon que deb et qu'il fallait pallier ces défaut dans le gestionnaire. Maintenant, rpm a sans doute rattrappé son retard mais ça n'empêche pas les outils au dessus de continuer à exister, c'est bien dommage.

              [^]Re: Re:

              Posté par rewind () le 03/03/2008 à 23:57. (lien). Évalué à 2.

              Oh mon dieu... et tu trouves ça fiable ? Je préfère nettement la gestion avec le système APT : il te dit ce qu'il peut faire et va faire avant de télécharger quoi que ce soit (hormis la liste des packages et leur metadonnées pour calculer la mise à jour et l'arbre des dépendances). Une fois que tu as dit oui, il télécharge et fait tout ce qu'il faut, ni plus ni moins. C'est simple et ça marche.

              • [^]Re: Re:

                Posté par IsNotGood () le 04/03/2008 à 02:09. (lien). Évalué à 0.

                > C'est simple et ça marche.

                Idem pour yum.
                M'enfin, j'ai compris le message.
                Mieux vaut l'ignorance, ça évite que les gens se posent des questions.

                • [^]Re: Re:

                  Posté par briaeros007 () le 04/03/2008 à 09:40. (lien). Évalué à 4.

                  Idem pour yum.
                  Tu viens de dire que ca ne marche pas , et que c'est _normal_ , et quand on t'en fait la remarque tu dis que ca marche.

                  Tu dis tout et son contraire quand on parle de fedora/rh... sans compter que tu a commencé a dire qq trucs sur "apt" (le méchant il cache tout) et quand certains t'on repris dessus, tu joue ton huitre et tu te ferme

                  M'enfin, j'ai compris le message.
                  Mieux vaut l'ignorance, ça évite que les gens se posent des questions.

                  --
                  Subete ga wakatta toki…watashi ga anta wo korosu.

    [^]Re: Re:

    Posté par fleny68 () le 03/03/2008 à 15:16. (lien). Évalué à 3.

    >> J'ai longtemps conseillé
    >> je conseille
    >> je l'envoie chez

    >Faites comme moi. Dites qu'il y a plein de distributions. Que >globalement Ubuntu/Suse/Mandriva/Fedora sont adaptées à un >nouveau. J'ajoutes seulement que s'il prend une Fedora, vu que j'ai >une Fedora, je pourrais plus facilement l'aider.

    Non. Moi c'est vous voulez essayer? Prenez ubuntu, il y a du monde et des forums actifs. Et oubliez mon téléphone. Maintenant j'ajouterai "ou Fedora" à la liste. J'évite de conseiller Suse à cause de Novell, Mandr* parce la pub m'est resté en travers de la gorge.

    Il parait qu'ubuntu a lancé une boite à idée. J'ai entendu parlé de promouvoir des trucs libres pendant l'installlation. J'espère que ça va pas finir comme Mandr* avec des pubs.

    Y'a que les très proches à qui je conseille une debian pour pouvoir les aider directement.

    • [^]Re: Re:

      Posté par IsNotGood () le 03/03/2008 à 17:00. (lien). Évalué à 2.

      > En parlant de plantage à cause d'un mauvais dvd, j'ai eu la cas. pour plantage pour le paquet liberations-fonts, qu'on n'imagine pas bloquant.

      Ouais. C'est comme ça depuis des années. Quand ça arrive c'est très casse couille. J'ignore si Fedora veut régler ce problème. Pour RHEL, Red Hat ne veut pas régler ce problème. Une installation RHEL doit bien se dérouler sans problème puisque Red Hat fait du support. Red Hat ne veut pas supporter des mauvaises installations.

      Il faut le comprend. Qu'on n'aime ou pas. Et si vraiment on n'aime pas, ben on va voir ailleurs.