Sortie de Fedora Core 4 test 1 pour i386/amd64/PPC/PPC64

Posté par . Modéré par Jaimé Ragnagna.
Tags :
0
16
mar.
2005
Red Hat
La Fedora Core 4 test 1 vient d'être officiellement annoncée.

On retrouve au menu Gnome 2.10 beta 2, KDE 3.4.0-rc1, Linux 2.6.11, gcc 4.0 mais surtout le support des architectures PPC et PPC64, qui vient donc s'ajouter aux architectures i386 et AMD64.

De même, au retrouve au rang des nouveautés remarquables le fameux logiciel Xen en version de développement (Xen permet de faire tourner plusieurs machines virtuelles sur un même ordinateur), ainsi qu'une implémentation native de Eclipse qui utilise directement gcj (et n'a donc plus besoin d'une VM propriétaire)

Attention, Fedora Core 4 test 1 reste une version de test (beta), il ne faut donc pas l'utiliser en production ou sur des systèmes critiques, et il faut s'attendre encore à rencontrer des bogues ou autres instabilités du système, à reporter sur le bugzilla de Red Hat Afin d'alléger Fedora Core, il existe Fedora Extra, que l'on peut trouver sur tous les bons miroirs.

À l'avenir, des paquets seront déplacés de Fedora Core à Fedora Extra, l'objectif étant d'obtenir une Fedora Core 4 qui tienne sur 4 CD

À noter que Yum sera préconfiguré pour utiliser Fedora Extra.

Plus d'info sur Fedora Extra ici

NB : Fedora Extra ne comporte que des programmes libres. Donc il n'y a pas mplayer, de lecteurs mp3, etc...
Pour ça, il faut jeter un oeil du côté de livna

Aller plus loin

  • # diverses infos

    Posté par . Évalué à 8.

    > On retrouve au menu Gnome 2.10 beta 2, KDE 3.4.0-rc1, Linux 2.6.11, gcc 4.0

    Précisons que gcc 4.0 est le compilateur par défaut. Il était déjà dispo dans FC3 mais pas utilisé par défaut.

    Enfin, il y a aussi OpenOffice 2.0 (1.9.83 actuellement).

    > le support des architectures PPC et PPC64

    Je crois que c'est PPC64 par défaut et compatibilité PPC (comme on le voit avec amd64 et i386). Ça ne passe pas par un chroot, ça utilise les capacités multilib de rpm/yum. Attention, ça ne marche pas avec apt et smart.

    > De même, au retrouve au rang des nouveautés remarquables le fameux logiciel Xen

    Quelques infos pour l'utilisation avec Fedora :
    http://www.fedoraproject.org/wiki/FedoraXenQuickstart(...)

    > il est faut s'attendre encore à rencontrer des bogues

    Il y en a un notable :
    https://bugzilla.redhat.com/beta/show_bug.cgi?id=151204(...)

    Sauvegardez votre MBR.

    > Afin d'alléger Fedora Core, il existe Fedora Extra, que l'on peut trouver sur tous les bons miroirs.

    Ce n'est pas le seul objectif de Fedora Extra. Par exemple si c'était l'objectif de Fedora Extra, eclipse (100 Mo) serait dans Fedora Extra.
    Expliquer Fedora Extra est assez compliqué. Le mieux est d'attendre que Red Hat finisse le boulot sur Fedora Extra et en donne précisément les objectifs pour avoir un descriptif.
    Celà a été très très très longuement abordé dans les mailings Fedora.
    Par contre, je tiens à préciser que Fedora Extra n'est pas synonyme de "sous-paquet" ou paquet laissé à l'abandon par Red Hat.

    > À l'avenir, des paquets seront déplacés de Fedora Core à Fedora Extra, l'objectif étant d'obtenir une Fedora Core 4 qui tienne sur 4 CD

    Objectif déjà atteind pour FC4 (sauf PPC qui tient sur 5 CD).
    A long terme, l'objectif est de réduire encore FC. Peut-être autour de 3 ou 2 CD.
    Puis peut-être d'avoir aussi des iso pour Fedora Extra.
    On voit que Fedora Extra a changé le "contrat" initial de Fedora Core. RHEL devait être basé sur Fedora Core, à l'avenir RHEL sera basé sur Fedora Core *et* Fedora Extra.

    Notons bien que Fedora Extra est en cours de développement et n'est pas très fournit pour FC4. Il va se remplir petit à petit jusqu'à l'arrivée de FC4 final.
    Pour FC3, Fedora Extra compte déjà 660 paquets.
    Fedora Extra supporte i386 et x86_64. Pas de PPC actuellement.



    Quelques stats d'utilisation de Fedora en serveur web :
    http://linuxfr.org/comments/547639,1.html(...)
  • # Multimédia pas libre ?

    Posté par . Évalué à 8.

    mplayer et lecteurs de MP3 non libres ??? Je veux bien que Red Hat soit américanocentriste, mais le rédacteur de la dépèche n'a aucune raison de l'être !

    En effet, ce n'est pas parce que quelques pays reconnaissent déjà les brevets logiciels que l'on peut qualifier des logiciels supportant des technologies telles mp3 et autres mpeg4 de non libres.

    Même si tel que c'est parti il y a des chances que ces logiciels deviennent illégaux en Europe ...
    • [^] # Re: Multimédia pas libre ?

      Posté par . Évalué à 1.

      > mplayer et lecteurs de MP3 non libres ???

      Pas libre dans le monde. Fedora n'est pas limité au pays qui ne reconnaissent pas les brevets.
      Mais merci pour ta mise au point.
      • [^] # Re: Multimédia pas libre ?

        Posté par . Évalué à 6.

        C'est une interessante question : est-ce que le DMCA/des brevets/des restrictions (comme l'utilisation MPEG-4 gratuite a des fins academiques) rend le code non libre ? mplayer est GPL par exemple, on peut dire qu'il est libre. ffmpeg qui contient des codecs mpeg-4 est aussi sous licence libre.

        Si dans un pays on interdisait mplayer, est-ce qu'au niveau de sa licence, cela le rend non libre ? Car dans ce cas beaucoup de logiciels sont concernes. En Chine, les librairies de cryptographie ne sont pas difusables. De meme, leur export des US est limite (et il a fallu par exemple passer par des copies du code sur papier pour pouvoir le faire). Mais est-ce que libgpg devient non libre dans ce cas ?
        • [^] # Re: Multimédia pas libre ?

          Posté par . Évalué à 2.

          Ce sont les états qui définissent ce qui est libre et ce qui ne l'est pas. Dans certains pays la presse n'est pas libre par exemple et ça n'a rien à voir avec les droits d'auteurs.
          La GPL, c'est limité aux droits d'auteur.
          • [^] # Re: Multimédia pas libre ?

            Posté par . Évalué à 5.

            D'accord, mais dans ce cas, ne pas fournir mplayer parce qu'il serait interdit dans certains etats n'est pas logique quand on fournit la lib de gpg ou ssh. On ne peut pas dire dans ce cas que mplayer n'est pas distribue car non libre.
            • [^] # Re: Multimédia pas libre ?

              Posté par . Évalué à 1.

              Fedora (et Red Hat) est aux USA. gpg et ssh sont autorisés aux USA.
              mplayer, etc n'est pas autorisé aux USA.

              > On ne peut pas dire dans ce cas que mplayer n'est pas distribue car non libre.

              On dit quoi alors ? Il est libre mais on n'a pas le droit ?
              • [^] # Re: Multimédia pas libre ?

                Posté par . Évalué à 3.

                >On dit quoi alors ? Il est libre mais on n'a pas le droit ?

                C'est justement ce que je voudrais savoir: est-ce que des restrictions legales rend la license libre caduque dans ce cas ?
              • [^] # Re: Multimédia pas libre ?

                Posté par . Évalué à 4.

                Ok, donc monde = USA, comme d'hab' quoi :)
                • [^] # Re: Multimédia pas libre ?

                  Posté par . Évalué à 1.

                  Les rpm qui sont litigieux sur leur contenus (mp3, xmms) sont sur livna.org

                  d'ailleurs livna.org est enregistré par un francais.
          • [^] # Re: Multimédia pas libre ?

            Posté par . Évalué à 2.

            La GPL, c'est limité aux droits d'auteur.

            Non la GPL et les droits d'auteur sont une chose totalement differente...
            • [^] # Re: Multimédia pas libre ?

              Posté par . Évalué à 2.

              Absolument pas !

              La validité de toute licence logicielle repose sur le droit d'auteur !
              (en France, du moins ... aux USA, ce serait le copyright)

              Pas de droits d'auteur, pas de GPL !

              Et je suis d'accord : quand on parle de liberté de la presse et liberté du logiciel, ce sont bien là deux choses différentes. Pour la presse, cela veut simplement dire qu'elle n'est pas censurée par l'état, pour le logiciel, ce sont les 4 fameuses libertés, qui sont elles accordées par les auteurs, et non l'état !
            • [^] # Re: Multimédia pas libre ?

              Posté par . Évalué à 5.

              La GPL étant une licence, elle est forcément basée sur le droit d'auteur, car c'est le droit d'auteur qui permet à l'auteur d'une oeuvre de choisir la licence selon laquelle il distribue son oeuvre
      • [^] # Re: Multimédia pas libre ?

        Posté par . Évalué à 1.

        Tu sais si tu pars sur ce point de vu il va plus de rester beaucup de chose de libre etant donne tous les brevets qui traines.

        La meilleur chose serait encore de retourne sous windows (et encore il parrait que windows viole des brevets dans VC-1)...
    • [^] # Re: Multimédia pas libre ?

      Posté par . Évalué à 1.

      Ah, mais je pense à un truc : même si les brevets logiciels passent, de toute manière, un brevet pourrait n'entraver que la commercialisation d'un logiciel, me trompe-je ?

      Ainsi, tant que tout se passe entre un projet communautaire et des utilisateurs, il n'y a pas vraiment à être inquiété, non ?

      (avant qu'on me réponde que cette restriction au non commercial ferait que ces logiciels ne seraient pas libres, je suis au courant ;) ... ce semi-libre ne serait qu'un pis-aller.)
      • [^] # Re: Multimédia pas libre ?

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

        > un brevet pourrait n'entraver que la commercialisation

        Non, il peut entraver la distribution, même gratuite (cf, justement, le sujet de ce thread sur la diffusion gratuite dans Fedora).
        • [^] # Re: Multimédia pas libre ?

          Posté par . Évalué à 1.

          De toute manière, si çà passe, la mentalité de nous, adorateurs du libre çà va être "gros doigt aux brevet".

          Depuis quand on veux nous empêcher de faire quelque chose... Je ne me drogue pas, je ne tue personne, je ne nuis à personne, je me contente d'écrire des lignes de codes et de partager gratuitement et librement mes réalisations.

          Ca n'as pas à être interdit par un brevet !!! Celà nuit à mes libertés individuelles.

          Ensuite, c'est déplorable de favoriser les entreprises "world company" pour enfoncer encore plus les petites boîtes et tuer dans l'oeuf toute création d'entreprise et toute innovation...

          Franchement !!! On codera de manière anonyme ou on ira coder dans des paradis fiscaux mais en tout cas "gros doigt aux brevets, que nos ù*£ù*ù de députés européens et autres politiciens verreux se mettent bien çà dans la tête" !!!

          Raaah, çà défoule ;o)
  • # eclipse en natif sur d'autres distrib

    Posté par . Évalué à 2.

    je me demandais si il etait possible d'utiliser la version native d'eclipse genre completement au hazard sur une debian?
    parceque de temps en temps j'entends parler d'eclipse, on me dit que c'est bien mais j'ai jamais voulu essayer parceque c'est en java. donc faut installer la jvm, en plus java avec la jvm c'est plus ou moins plus lent que du natif (je crois que j'ai reussi a eviter le troll la, non?).
    quelqu'un saurait donc si c'est possible?
    • [^] # Re: eclipse en natif sur d'autres distrib

      Posté par . Évalué à 1.

      Si c'est possible avec Fedora, c'est possible avec Debian. Si ce n'est pas fait, je ne sais pas pourquoi.

      > la version native d'eclipse

      Ce n'est pas la première fois qu'il y a une version native d'eclipse (la première fois c'était pour RHEL 3). Par contre le niveau de gcj et gij permet de se passer des VM proprios dans beaucoup de cas. Jonas, Jpackage et gcj font de gros efforts pour marcher sans accroc et sans vm proprio. La démo de la news utilise eclipse compilé avec gcj et utilise gij pour la démo (à visualiser, c'est très instructif sur gnome-java et libglade).

      Tomcat et Jonas est maintenant exploitable avec gcj :
      http://www.peakpeak.com/~tromey/blog/2005/03/14/(...)

      C'est un début. Tout ne doit pas marcher nickel.
      • [^] # Re: eclipse en natif sur d'autres distrib

        Posté par . Évalué à 2.

        oui c'est bon j'ai trouve
        http://fincos.homeip.net/Eclipse3gcj4debian(...)
        par contre d'apres ce que j'ai compris c'est un peu lourd a compiler...

        Compiling Eclipse require you, at least 1 Gb of free disk space, installing a number of development packages, and at least 256 Mb of phisical ram and an amount of swap space. I compiled it in a PIII 600 MHz 256 Mb ram, 128 Mbyte of swap: it requires 1 day.

        tant pis...
        mais bon si jamais quelqu'un le compile et fait des package ca pourrait m'interesser.
        • [^] # Re: eclipse en natif sur d'autres distrib

          Posté par . Évalué à 2.

          laissez tomber je suis trop un blaireau...
          sur la meme page, y a un depot pour les packages debian...
          • [^] # Re: eclipse en natif sur d'autres distrib

            Posté par . Évalué à 1.

            bon ben j'en suis arrive la :
            libswt3.0-gtk2-jni: Dépend: libgcc1 (>= 1:4.0-0pre6ubuntu4) mais 1:4.0-0pre5 devra être installé
            Dépend: libstdc++6 (>= 4.0-0pre6ubuntu4) mais 4.0-0pre5 devra être installé

            ca m'embete un peu d'installer des packages ubuntu...
  • # installation à partir d'un disque dur

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

    Bonjour,
    Puisqu'il y a un expert dans la salle, j'aimerai poser cette question :
    est il possible d'installer une Fedora avec les paquets sur le disque dur, comme on peut le faire avec une Mandrake ?
    Merci,

    Y.
    • [^] # Re: installation à partir d'un disque dur

      Posté par . Évalué à 3.

      Faut copier les isos binaires (toutes ?) sur une partition puis installer sur une autre partition.
      Tu peux utiliser la mini image boot.iso pour booter. Tu peux aussi copier vmlinuz et initrd sur le disque dure et booter avec grub.

      Il faut passer le paramètre "askmethod".

      La doc RHEL 4 :
      https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/x8664-m(...)
    • [^] # Re: installation à partir d'un disque dur

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

      Il y a moyen de ruser si tu ne veux pas graver les CDs :
      http://www-2.cs.cmu.edu/~colohan/docs/fedora_upgrade.html(...)
      (mais bon, avec des CDRW c'est assez peinard)
    • [^] # Re: installation à partir d'un disque dur

      Posté par . Évalué à 1.

      Malheureusement ça ne marche pas actuellement :
      https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150887(...)
      • [^] # Re: installation à partir d'un disque dur

        Posté par . Évalué à 0.

        J'ai oublié, il y aura un boot.iso (ou vmlinuz/initrd) corrigé dans un ou jours dans rawhide.
      • [^] # Re: installation à partir d'un disque dur

        Posté par . Évalué à 1.

        Il y a un fix dans le bug report. Malheureusement je n'ai pas l'environnement de développement qui va bien (je n'ai pas envis de mettre à jours ma FC3 "au hazard").
        Pas grave, il suffit de dépaqueter initrd, utiliser un éditeur hexa et corriger sbin/loader, refaire initrd.
        L'installation passe sans gros accro mais il y a des problèmes d'affichage.

        J'ai fait un test rapide.
        Commençons par les points positifs :
        Le boot est plus rapide. Ceci dit, je m'en fous un peu, je ne boote pas toutes les heures.
        Gtk est plus rapide sur un point qui m'a longtemps agacé. Lorsque les images ne sont pas en cache, c'est lent voire très lent. Typiquement lorsqu'on clique sur le menu gnome. Maintenant c'est beaucoup beaucoup plus rapide même si ce n'est pas instantanné. J'ai fait un petit programme pour vider le cache et confirmer cette impression. Je confirme et ce n'est pas qu'une impression. Idem pour le "réveil" d'une appli qui dormait en swap. C'est une très agréable surprise. Autre point positif, c'est la rapidité de chargement d'evolution. Impressionnante.
        Donc globalement gnome a gagné en vitesse mais surtout dans un domaine qui m'a longtemps agacé.

        Les points négatifs :
        C'est buggué et des bugs très génants. yum marche mal (option "--exclude" non prise en compte et donc quasi impossibilité de mettre à jours car Rawhide est un peu cassé), l'affichage des consoles est corrompu, $LANG n'est pas fixé par GDM, des kernel panic, firstboot n'est pas lancé (surement le passage à python 2.4), certains programmes plantent "tout seul", etc...
        Bluecurve a été légèrement retouché. Je ne suis pas convaincu par ces modifs.

        Certe, les "test 1" de Fedora sont en général assez mauvaises. Mais là c'est impressionnant.
        Ceci dit, il n'y a rien de dramatique. Je pense qu'il y a quelques bugs côté noyau et gcc-4 qui ne seront pas facile à traquer, le reste est de la mise au point classique.

        Je suis très confiant pour la version finale même si j'ai quelques craintes côté gcc-4 et OOo 2.0 qui sont des gros morceaux. La situation est beaucoup plus saine que FC2 (Selinux & xorg) et FC3 (selinux (activé par défaut), bash3 mais surtout udev & hal ont été assez long à mettre au point). FC3 (et FC1) a été un grand cru en terme de qualité (hors quelques bugs de jeunesses vites corrigés). FC4 sera, je le pense, un grand cru et probablement encore meilleur que FC3 car il n'y a pas d'éléments de base "révolutionnaires" et gnome/kde sont arrivés assez tôt dans le cycle de développement de la distribution.

        Pour ma part je vais attendre la test 2 pour tester et faire du bugfix. Les bugs actuels sont trop évidents ou trop complexes (kernel et peut-être gcc) pour que ma contribution soit utile. Puis il faut bien le reconnaitre, ce n'est pas très enthousiasmant de bosser dans un environnemnt aussi buggué.

Suivre le flux des commentaires

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