Fedora 9 : une version sulfureuse

Posté par  . Modéré par j.
0
14
mai
2008
Fedora
La grande famille de Fedora est heureuse de vous annoncer, après 7 mois de développement, la naissance de « Sulphur » ou Fedora 9.

Cette version majeure dans le développement de la distribution Fedora offre un grand nombre de nouveautés destinées à simplifier la vie.

Concernant l'aide aux utilisateurs francophones, l'équipe ainsi que les membres de Fedora-FR seront heureux de vous accueillir à cette adresse : http://www.fedora-fr.org/

Article rédigée par les ambassadeurs francophones de FedoraProject. Quelques nouveautés :

Côté environnement graphique :

KDE 4.0.3
L'arrivée de KDE4 et la constitution du groupe d'intérêt KDE au sein de FedoraProject est l'occasion de faire de KDE un citoyen de première classe dans le projet.
Fedora 9 est la première distribution à installer par défaut KDE 4.x et ceci constitue le premier pas vers un meilleur bureau KDE sous Fedora.

GNOME 2.22
Une importante sortie pour FedoraProject avec le développement de gvfs principalement par le développeur Fedora Alexander Larsson. Fedora a également réécrit GDM pour une meilleure intégration avec {Console,Policy}Kit.

Côté bureautique :

OpenOffice 2.4

Côté réseau :

NetworkManager
* Configuration réseau filaire, Wifi, GSM/CDMA et PPP en une seule interface.
* Configuration d'accès VPN (OpenVPN & Compatible Cisco VPN Client (VPNC)).

Côté internet :

Firefox 3 (Béta5).

Swfdec
greffon libre qui vous permet de lire du contenu Flash depuis votre navigateur. Celui-ci s'appuie sur GStreamer pour le multimédia

Côté système :

PreUpgrade
Système de mise à jour automatique de la nouvelle version Fedora sans média (cd/dvd).

Linux 2.6.25

Upstart
Remplacement du vieillissant ''init'' par le service Upstart (développé par Ubuntu) ce qui a pour résultat immédiat un démarrage et une extinction du système très rapide.

Xorg 7.3
Dans la continuité de l'opération "Need For Speed", Fedora a consciencieusement traqué les goulots d'étranglement dans Xorg afin d'accélérer son démarrage.

Fedora introduit la gestion optionnelle du modsetting pour les cartes Intel !

La version incluse est une pré-version de Xserver 1.5 qui en combinaison avec le noyau 2.6.25 introduit une meilleure collaboration entre Xorg et le noyau, une meilleure gestion du sous-système PCI et également un meilleur support du hotplug.

Désormais, la gestion du double-écran sera simplifiée grâce à une super applet de gestion.

Gestion centralisée des dictionnaires
Un seul et unique dictionnaire pour chaque langue, mais pour toutes les applications (OpenOffice, FireFox, Thunderbird, Gnome, KDE...).

Anaconda (Gestionnaire d'installation amélioré)
* Redimensionnement de partition.
* Gestion du système de fichier Ext4 (expérimental).
* Chiffrement de partition.
* Abandon de Kudzu pour udev/hal pour meilleur reconnaissance des composants matériels.

PackageKit
Implémentation d'un nouveau gestionnaire de paquets alternatif.
L'objectif de PackageKit est de fournir un cœur commun à tous les systèmes de paquetages et faciliter la vie des distributions.

RPM Fusion
RPM Fusion ne fait pas à proprement parler partie de FedoraProject, mais c'est une initiative importante au sein de la communauté.
Trois des principaux dépôts tiers (Dribble, Freshrpms et Livna) ont décidés de fusionner pour fournir plus de paquets, partager des ressources communes et améliorer la qualité.

K12Linux
Fedora intègre la distribution LTSP (Linux Terminal Server Project) K12ltsp en tant que saveur officielle sous le nom de K12Linux. K12Linux est l'intégration de LTSP-5 dans FedoraProject en collaboration avec la communauté LTSP.org.
Un grand merci à Eric Harrison (core developer de LTSP et fondateur de K12ltsp) et à Warren Togami (fondateur du projet Fedora).

FUNC (Fedora Unified Controller)
Module Python afin de faciliter la gestion d'un parc informatique via XML-RPC/SSL.

LivePersistence
Vous pourrez distribuer des clés USB Fedora pré-chargées et conserver vos paramètres et données personnelles.

OpenJDK
Fruit de la collaboration entre RedHat et Sun, OpenJDK 1.6 (Java 6) remplace IcedTea (Java 7)

Côté développeur :

GCC 4.3
Intégration de GCC 4.3 avec le support expérimental de C++ 0x, un mode parallèle de la STL, que Fedora 9 fournira à sa sortie.

Eclipse 3.3 (Europa)
Cette version est fournie par défaut mais la mise à jour vers Eclipse 3.4 (Ganymède) est prévue ultérieurement.

Cette version est la première de Paul Frields nouveau Project Leader de Fedora et premier Project Leader issu de la communauté Fedora elle-même.

Aller plus loin

  • # Re:

    Posté par  . Évalué à 9.

    > PreUpgrade

    Malheureusement, PreUpgrade (pour mise à jour vers F9) n'a pas encore atteind les dépôts accessibles via un "yum install preupgrade".

    Pas de panique, vous trouverez les preupgrade qui vont bien ici :
    http://skvidal.wordpress.com/2008/05/13/looking-for-a-preupg(...)

    Preupgrade sur fedoraproject.org (avec des copies d'écran) :
    http://fedoraproject.org/wiki/Features/PreUpgrade

    Interview sur PreUpgrade :
    http://www.redhatmagazine.com/2008/04/15/interview-fedora-de(...)

    > * Gestion du système de fichier Ext4 (expérimental).

    Attention, grub ne sait pas lire du ext4. Donc si on veut tester ext4 il faut une partition /boot (en ext3 par exemple). Je précise car on le sait qu'à la fin de l'installation :-)

    > RPM Fusion

    Malheureusement RPM Fusion n'est pas encore prêt. Mais il n'est pas abandonné. Pour ceux qui vont vers livna aujourd'hui, il est prévu une migration en douceur.

    > FUNC (Fedora Unified Controller)
    > Module Python afin de faciliter la gestion d'un parc informatique via XML-RPC/SSL.

    Ce n'est pas un module python, mais on peut faire des modules python pour func (il y en a déjà quelqu'uns).
    https://fedorahosted.org/func

    Dans le même esprit (pour admin), notons aussi Augeas :
    http://www.augeas.net/

    Très intéressant.


    > OpenJDK
    > Fruit de la collaboration entre RedHat et Sun, OpenJDK 1.6 (Java 6)

    Maintenant c'est OpenJDK. Contrairement à IcedTea, il n'est pas très lié à Red Hat.
    M'enfin, il y reste encore beaucoup de patchs de IcedTea :-)

    > Intégration de GCC 4.3 avec le support expérimental de C++ 0x

    C'est plus expérimental je crois. C'est initial. Le chemin est encore (très) long.


    > Cette version est la première de Paul Frields

    Le mot (et ses réflexions) du "boss" sur F9 :
    http://www.redhat.com/archives/fedora-announce-list/2008-May(...)

    L'annonce de F9 par fedoraproject (fun comme d'habitude) :
    http://www.redhat.com/archives/fedora-announce-list/2008-May(...)

    L'annonce par Red Hat (moins fun) :
    http://www.redhat.com/about/news/prarchive/2008/fedora9.html
    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      > C'est plus expérimental
      C'est plus qu'expérimental
    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      Pour la petite histoire, le nom Sulphur a donné du fil à retordre à l'équite artistique. En effet, le sulphur (soufre) fait passer à des mauvaises odeurs. Il a donc été viré de l'image de fond du bureau même si d'un point de vu uniquement visuel c'était sympa.
    • [^] # Re: Re:

      Posté par  (Mastodon) . Évalué à 3.

      J'essaie de trouver de la doc mais c'est dur de s'y retrouver dans tout ce merdier de Java/OpenJDK/IcedTea alors j'aimerais bien que quelqu'un m'explique. Ce que j'ai compris jusqu'à présent :

      Sun a décidé de libérer Java (enfin !) à partir de la version suivante soit la version 7 (quand je dis Java, je veux dire tout Java, donc le JDK, pas seulement la machine virtuelle). Mais ils pouvaient pas tout libérer notamment à cause de bout ne leur appartenant pas. D'où le projet IcedTea qui avait pour but de récupérer tout ce qui était récupérable dans le Java libéré et de compléter avec des morceaux d'autres projets (Classpath me semble-t-il) donc jusque là, on parle toujours de Java 7. J'ai tout bien compris ?

      Maintenant, je vois OpenJDK, Java 6. Alors c'est quoi ça ? C'est le nom donné au Java libéré par Sun ? Pourquoi c'est pas du Java 7 ? Je comprend plus là...
      • [^] # Re: Re:

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

        Peut être parce que simplement OpenJDK est encore en développement ... et que la version 7 n'est pas encore sortie.

        Ce n'est pas à RedHat qu'il appartient de sortir la prochaine version de Java, c'est à Sun. Et ils ne l'ont pas encore fait.

        De plus cela m'étonnerait que la version 7 de Java sorte sans améliorations par rapport à la version 6 (à part la libération du code source). Car cela signifirait finalement que la spécification Java 6 == spec Java 7.
      • [^] # Re: Re:

        Posté par  . Évalué à 7.

        Java a libéré des gros morceaux de Java 6: OpenJDK mais ça n'était pas utilisable ni même compilable par une chaine de compilation libre.
        Le plan initial était de concentrer les efforts sur Java 7 qui doit être 100% libre (c'est un objectif pour la release). Et RedHat a retroussé ces manches et a concocté sa propre version d'OpenJDK 7 IcedTea en comblant les trous et en permettant à OpenJDK 7 d'être compilable par une chaine libre par exemple GCJ.
        Entre temps, on s'est rendu compte que Java 7 ne serait pas terminé avant 2009 (on discute encore les spécifications actuellement) et qu'OpenJDK tel quel était inutilisable par les distributions libres. Sans oublier le risque que les gens présument le comportement de Java 7 à partir du comportement d'IcedTea alors que celui-ci est loin d'être terminé.
        Sun et RedHat se sont entendu pour "backporter" les patchs d'IcedTea dans OpenJDK + accord sur l'utilisation de la marque Java dans RHEL.
      • [^] # Re: Re:

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

        >>> Maintenant, je vois OpenJDK, Java 6. Alors c'est quoi ça ? C'est le nom donné au Java libéré par Sun ? Pourquoi c'est pas du Java 7 ? Je comprend plus là...

        En même temps il suffit de cliquer sur le premier lien de la dépêche pour tomber sur un sommaire général des nouveautés. Dans ce sommaire il y a un chapitre sur Java qui explique tout :

        http://docs.fedoraproject.org/release-notes/f9/fr/sn-Java.ht(...)
    • [^] # Re: Re:

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

      Pour ceux qui ne peuvent pas utiliser leur levteur CD/DVD (problème matériel :( ) il existe rinse qui devrait permettre d'installer Fedora:

      http://xen-tools.org/software/rinse/

      par contre je n'ai pas encore testé. Si quelqu'un veut faire un retour d'expérience.
    • [^] # Re: Re:

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


      > FUNC (Fedora Unified Controller)
      > Module Python afin de faciliter la gestion d'un parc informatique via XML-RPC/SSL.

      Ce n'est pas un module python, mais on peut faire des modules python pour func (il y en a déjà quelqu'uns).
      https://fedorahosted.org/func


      Si si c'est bien un module Python : https://fedorahosted.org/func/browser.
      • [^] # Re: Re:

        Posté par  . Évalué à 2.

        > Si si c'est bien un module Python

        Non ou pas seulement. Il y a les programmes func, func-inventory, func-create-module, etc.
        Ces derniers utilisent des modules.

        Peut-être qu'un jour il y aura libfunc avec func comme utilisateur. Mais ce n'est pas le cas aujourd'hui.
    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      Petite vidéo du boss sur F9.
      Intéressant pour ceux qui ne connaissent pas Paul Frields :
      http://www.redhat.com/v/magazine/ogg/Fedora9PaulFrields.ogg
  • # Goulots d'étranglement de X

    Posté par  . Évalué à 1.

    Ou peut on trouver (de la doc sur) le travail qui a été fait sur les goulots d'étranglement de xorg ?
    Ca m'interesse :)
    Merci

    Sinon, upstart est bluffant. Mais einit me semble un peu plus rapide (à vue de video) ?
    http://www.youtube.com/watch?v=cY8MWwbESy4
    http://einit.jyujin.de/node/116
    • [^] # Re: Goulots d'étranglement de X

      Posté par  . Évalué à 2.

      > Ou peut on trouver (de la doc sur) le travail qui a été fait sur les goulots d'étranglement de xorg ?

      Ce n'est pas vraiment un "goulot d'étranglement", c'est pour raccourcis le temps de démarrage de Xorg :
      http://fedoraproject.org/wiki/Features/OneSecondX

      > Sinon, upstart est bluffant.

      F9 est en mode compatible SysVinit. Donc il n'y a pas de gain ici ou très peu (du moins pour F9). Entre appeler /etc/rc.d/rc5.d/S27named depuis le vieux init ou depuis upstart, ça ne change pas grand chose.
  • # firefow 3.0 beta 5

    Posté par  . Évalué à 2.

    Je comprends pas cette manie de vouloir distribuer firefox 3.0 beta 5 sur une version stable d'une distribution.

    sur le site de mozilla on peux lire :
    Firefox 3 Beta 5 is available in 45 languages as a public preview release intended for developer testing and community feedback. It includes new features as well as dramatic improvements to performance, memory usage and speed.

    Et c'est plutôt vrai :
    - ça plante
    - ça bug (des blocages inexliqué lors du chargement de certaines pages, puis ça repart)
    - l'integration avec gnome est encore bancale (ne prends pas les thèmes des icones installés, mais celles de gnome avant l'installation des thèmes)

    bref... je comprends pas.
    • [^] # Re: firefow 3.0 beta 5

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

      Peut être parce que Mozilla met trop de temps a sortir ses releases ... Et que tout le monde demande la nouvelle version (qui est déjà obsolète niveau standards)

      C'est pareil que pour NetworkManager ... Fedora packagent la version 0.7 (depuis un bout de temps en fait) alors que la dernière version stable est la 0.6.5
      • [^] # Re: firefow 3.0 beta 5

        Posté par  . Évalué à 5.

        Fedora *développe* NetworkManager, d'ailleurs depuis le départ de Robert Love de Novell, Dan Williams ne reçoit quasiment plus aucune contribution externe.
        NM 0.7 est une réécriture de NM, il est nettement meilleur que la branche précédente mais il est en développement actif.
        Il n'est pas stable au niveau du code mais l'est suffisamment en fonctionnement pour remplacer le bon vieux system-config-network dans Fedora 9.
        http://fedoraproject.org/wiki/Interviews/DanWilliams


        Quant à Firefox 3, c'est principalement l'intégration de xulrunner et pouvoir mettre à jour les paquets concernés par les changements d'API qui intéressait Fedora. Firefox 3 casse de nombreux paquets, ça aurait été problématique de repousser la tâche à plus tard.
        • [^] # Re: firefow 3.0 beta 5

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

          J'ai toujours trouvé wicd bien meilleur que network-manager.
          C'est la première chose que je fais après l'installation : virer nm et le remplacer par wicd.
          • [^] # Re: firefow 3.0 beta 5

            Posté par  . Évalué à 7.

            NetworkManager et WICD n'ont pas les mêmes ambitions, le premier est un véritable framework réseau versatile et le second un frontend aux wireless tools.
            Tu devrais essayer la branche 0.7 qui est nettement meilleure que la branche 0.6.x

            Si tu veux mon opinion d'empaqueteur: WICD est typiquement le logiciel ubunto-centrique, bref un cauchemar à empaqueter.
            A l'origine, le projet ne fournissait pas de tarballs des sources et la gestion des branches se faisait au petit bonheur la chance.
            Suite à ma demande, le projet fournit désormais un tarball des sources mais en vrac (avec pas mal de code non pas spécifique à Ubuntu mais à plusieurs versions !), pas un makefile, pas un script d'installation: nada. En gros, si tu n'utilises pas Ubuntu, tu peux aller te torcher ou installer manuellement les fichiers.
            Bref, WICD c'est clairement du bricolage.


            D'ailleurs WICD n'est pas très populaire en dehors d'Ubuntu.
            • [^] # Re: firefow 3.0 beta 5

              Posté par  . Évalué à -1.

              > En gros, si tu n'utilises pas Ubuntu, tu peux aller te torcher ou installer manuellement les fichiers.
              N'importe quoi (fonctionne parfaitement sous arch)
              • [^] # Re: firefow 3.0 beta 5

                Posté par  . Évalué à 1.

                > N'importe quoi (fonctionne parfaitement sous arch)

                Bravo arch, mais pas bravo Ubuntu :-)
              • [^] # Re: firefow 3.0 beta 5

                Posté par  . Évalué à 4.

                Où est-ce que j'ai dit que WICD ne fonctionne pas?
                J'ai juste dit que son installation ailleurs que sur une Ubuntu était pénible:
                * pour l'utilisateur qui l'installe à partir des sources. T'as regardé le contenu de la tarball des sources?
                * pour l'empaqueteur qui doit se faire chier à scripter l'installation et corriger les ubuntu-ismes dans le code.

                Regarde la page concernant l'installation sur Fedora7
                http://wicd.net/wiki/doku.php?id=fedora
                Et encore, à l'époque où j'avais empaqueté le bousin, c'était pire encore. Vu le peu d'intérêt de l'upstream pour rendre leur machin portable sur d'autres distributions, je ne l'ai pas proposé dans FPC.
                • [^] # Re: firefow 3.0 beta 5

                  Posté par  . Évalué à 2.

                  Bon, je viens de regarder le PKGBUILD de wicd.
                  Je suis d'accord que ça a l'air un sérieux merdier à empaqueter, mais ton "c'est ubuntu-centriste", je trouve ça un peu fort en café. Moi, je vois juste un auteur qui a beaucoup de mal à faire un script d'installation potable pour son programme ou ne s'est pas fait chier à en faire un. Je vois pas en quoi empaqueter ça pour Ubuntu est fondamentalement plus simple...

                  Si d'ailleurs tu as une bonne doc sur LA manière de faire un bon script d'installation pour un programme python, je suis certain que l'auteur ne te crachera pas à la figure... (non, les autotools ne sont pas une réponse acceptable...)
                • [^] # Re: firefow 3.0 beta 5

                  Posté par  . Évalué à 6.

                  Désolé pour le double-post, j'ai répondu trop vite...

                  > Regarde la page concernant l'installation sur Fedora7
                  Pour le fun, regardons wicd.redhat.patch:

                  --- ./opt/wicd/daemon.py.sdg 2007-07-08 23:56:54.000000000 -0400
                  +++ ./opt/wicd/daemon.py 2007-09-16 18:30:30.000000000 -0400
                  @@ -51,8 +51,8 @@

                  class FlushWriter:
                  def __init__(self):
                  - print os.getcwd()
                  - self.file = open('data/wicd.log','w')
                  + if not PIDFile: print os.getcwd()
                  + self.file = open('/var/log/wicd.log','w')
                  self.file.write(self.__getPrettyTime() + ' :: ')


                  Changement de la location de wicd.log. Pourquoi était-ce un répertoire relatif avant ? Je suppose que c'est parce que l'auteur ne sait pas faire l'equivalent de gcc -DDATADIR=... à l'installation pour python. C'est très compréhensible, je n'ai pas trouvé de doc potable là dessus.


                  @@ -122,8 +122,8 @@

                  DoAutoConnect = True

                  - if len(sys.argv) > 1:
                  - if sys.argv[1] == "--do-not-scan":
                  + for opt in sys.argv[1:]:
                  + if opt == "--do-not-scan":
                  print "--do-not-scan detected, not autoconnecting..."
                  DoAutoConnect = False

                  Ne pas obliger --do-not-scan à ne pas être la première option: quel comportement ubuntu-centriste inacceptable !


                  @@ -766,6 +766,11 @@
                  ## fork from the parent terminal

                  if True: #for easy disabling
                  + for opt in sys.argv[1:]:
                  + if opt.startswith('-P'):
                  + PIDFile = opt[2:]
                  + break
                  + else: PIDFile = None
                  try:
                  pid = os.fork()
                  if pid > 0:

                  Ajout d'une option pour choisir le fichier PID. N'a de sens qu'avec la suite du patch


                  @@ -783,7 +788,10 @@
                  try:
                  pid = os.fork()
                  if pid > 0:
                  - print "wicd daemon: pid " + str(pid)
                  + if PIDFile:
                  + print >>open(PIDFile,'wt'),str(pid)
                  + else:
                  + print "wicd daemon: pid " + str(pid)
                  sys.exit(0)
                  except OSError, e:
                  print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror)

                  Ajout de la gestion d'un lock par fichier de PID. Ne pas en avoir est tellement ubuntu-centriste que c'en est gerbant...


                  --- ./etc/init.d/wicd.sdg 2007-03-30 09:14:30.000000000 -0400
                  +++ ./etc/init.d/wicd 2007-09-16 18:30:53.000000000 -0400

                  Puisque tu as déjà fait plein de paquets pour Fedora, je ne t'apprendrais rien si je te dis que c'est la stratégie de la majorité des projets libres: l'auteur fournit le script d'init pour SA distribution. Pour les autres, soit il y a des contributions et l'auteur se fait un plaisir de les intégrer, soit il n'y en a pas et c'est le boulot du packageur.

                  Je viens également de regarder les sources, et je viens de voir dapper.py et edgy.py. Quoi, me serais-je fourvoyé ? Regardons de plus prêt:
                  $ head -n 3 dapper.py
                  ########
                  ## DO NOT RUN THIS FILE DIRECTLY
                  ## USE TRAY.PY INSTEAD
                  $ head -n 3 edgy.py
                  ########
                  ## DO NOT RUN THIS FILE DIRECTLY
                  ## USE TRAY.PY INSTEAD
                  $ cat tray.py
                  [coupage d'une partie inintéressante]
                  import gtk
                  if gtk.gtk_version[0] >= 2 and gtk.gtk_version[1] >= 10:
                  import edgy
                  else:
                  import dapper

                  Donc il se trouve que pour l'icone de notification, il gère GTK < 2.10 dans dapper.py et GTK >= 2.10 dans edgy.py. OK, il a fait le crime de lèse majesté de mal nommer deux fichiers. Quelle horreur !
    • [^] # Re: firefow 3.0 beta 5

      Posté par  . Évalué à 7.

      effectivement. Ils auraient dû faire pression sur Mozilla suggérer à l'Upstream de sortir Firefox 3 en même temps qu'Unbuntu que Fedora !

      Blague à part, cette nouvelle mouture me semble vraiment comporter beaucoup de nouveauté intéressantes. Ca donne envie de se mettre à Fedora pour voir tout cela ;)

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

    • [^] # Re: firefow 3.0 beta 5

      Posté par  . Évalué à 8.

      Tout simplement parce que Fx 2 aurait été considéré comme "obsolète" dans quelques semaines/mois, alors que Fx3 va bientôt devenir la version actuelle officielle.
      Et puis, Fx3 cassant beaucoup de choses (changement d'API) certaines distrib' ont décidé de se taper e sale boulot de suite (comme c'est le cas pour F9) et d'autres ont préféré attendre la prochaine release (comme c'est le cas pour Mandriva).

      Par contre, je ne trouve pas que Fx3 buggue et plante tant que ça... J'ai même l'impression qu'il est bien plus rapide et plus léger que Fx2 !
    • [^] # Re: firefow 3.0 beta 5

      Posté par  . Évalué à 3.

      Euh... Quel intérêt ? La possibilité d'avoir une version qu'il sera facile de mettre à jour lors des sorties des RCs puis des versions finales, ce n'est pas suiffisant ?

      Coté bogue, cette saleté de flash est assez coupable ici.

      Si tu ne veux pas de cette version, utilise donc Epiphany.
      • [^] # Re: firefow 3.0 beta 5

        Posté par  . Évalué à 5.

        Coté bogue, cette saleté de flash est assez coupable ici.

        Suffit de ne pas l'installer.
        Gnash rempli très bien son office - Youtube/Daily - et tu contrôles la lecture ou non du fichier. <-- Merci pour cela!
        Et il tourne sur 64bits! Pas de chipotage dégueux avec des libs32 à gauche à droite.
        Alors certes, je me vois fermer la porte aux jeux flash en ligne - qui marchait de toute façon pas super avec flash™-linux, aux sites mal foutus, mais je m'en fout car ça ne me concerne pas.
    • [^] # Re: firefow 3.0 beta 5

      Posté par  . Évalué à 2.

      Bin pour Fedora ça a un sens, après tout c'est une distrib pour que RedHat integre des nouvelles technos (c'est la même logique qui fait installer KDE4), si tu veux du stable utilise une autre distrib..

      Mais pour Ubuntu l'integrer dans une version soi-disant 'support a long terme', je suis d'accord c'est du n'importe quoi.

      Avec une bourde pareille, Ubuntu LTS n'est pas près de concurrencer RHE!
      • [^] # Re: firefow 3.0 beta 5

        Posté par  . Évalué à 3.

        Si il y a eu des bourdes dans Ubuntu 8.04, Firefox 3 n'en fait pas partie.
        La mise à jour FF2 -> FF3 n'a rien de trivial, de nombreux paquets sont cassés, et il faut non seulement réparer mais également tester, c'est le rôle du cycle de développement.
        Ce qui aurait crétin, aurait été de faire la maj dans le cycle de support.
        Pour vous donner une idée, voici le plan de travail de Fedora à ce sujet:
        http://fedoraproject.org/wiki/Features/XULRunner
        http://fedoraproject.org/wiki/Releases/FeatureXULRunnerAPICh(...)

        Et si ça c'est bien passé dans Fedora, c'est grâce à C. Aillon qui a coordonné la mise à jour.
        • [^] # Re: firefow 3.0 beta 5

          Posté par  . Évalué à 4.

          >Si il y a eu des bourdes dans Ubuntu 8.04, Firefox 3 n'en fait pas partie.

          Pas d'accord..

          >Ce qui aurait crétin, aurait été de faire la maj dans le cycle de support.

          La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..

          Ou alors il faut renommer LTS, car prétendre avoir un support a long terme en utilisant des beta-versions pour diminuer les futurs couts de support, c'est trompeur je trouve.
          • [^] # Re: firefow 3.0 beta 5

            Posté par  . Évalué à 2.

            > La nous sommes d'accord, donc pour moi la seule solution 'correcte' aurait été de rester en FF2 pendant tous le cycle de support: c'est ce genre de chose que fait RHE..

            Firefox 2 est en fin de vie, Ubuntu LTS est supporté pendant 3 ans pour la partie desktop. Cela signifie que Canonical aurait du maintenir seule Firefox 2 pendant près de 3 ans ou bien laisser s'accumuler les failles de sécurités, ce n'est pas clairement pas tenable pour eux.
            Quant à RH, ils comptent inclure Firefox 3 dans RHEL 5.2 (actuellement en béta) et ce malgré qu'ils disposent d'une forte expertise dans le domaine (RH emploie pas mal de développeurs Mozilla et pas mal de développeurs Mozilla contribuent à Fedora). Mais avant de lâcher RHEL 5.2, celle-ci sera blindé de tests

            Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier (il aurait fallu décaler la sortie) et le problème récurrent dans la chaine de test.
            Pour le premier, Mark Shuttleworth s'est encore plus enfoncé avec son dernier billet, quant au second, il faut embaucher une vraie équipe de testeurs y a pas 36000 solutions.
            Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.
            • [^] # Re: firefow 3.0 beta 5

              Posté par  . Évalué à 4.

              > Mais avant de lâcher RHEL 5.2, celle-ci sera blindé de tests

              C'est du desktop seulement :-)
              Red Hat ne va pas faire des tests de non régression ou des benchs comme il le fait pour les systèmes fichiers ou le noyau.

              > Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier

              Le débat est totalement faussé. Ubuntu LTS est une distribution comme Mandriva / Fedora / OpenSuSE / etc ou comme RHEL SLES ?
              Si c'est une distribution comme Fedora ou Mandriva, c'est grosso-modo une bonne distribution (peut-être pas le meilleur cru).

              Mais ça n'a rien à voir avec une RHEL.

              > Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.

              C'est supporté 3 ans, LTS est le nom pour ça. Donc c'est digne de LTS.
              Fedora a aussi eu ces "LTS" (Fedora Legacy qui n'existent plus aujourd'hui).

              Mais LTS != RHEL ou SLES.
              En tout cas pour la 04-08.
              • [^] # Re: firefow 3.0 beta 5

                Posté par  . Évalué à 2.

                Vu la double nature d'Ubuntu (distribution communautaire/commerciale), on peut attribuer deux sens au terme LTS. Ton analyse est tout à fait pertinente.

                NéanmoinsMark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE. Du moins, il y a une volonté de les concurrencer, comme l'indique le revirement stratégique de Canonical sur les serveurs, leur grille tarifaire (ils sont plus cher que RedHat à service plus ou moins égal). Le récent billet de Mark S. est suffisamment explicite à ce sujet.
                • [^] # Re: firefow 3.0 beta 5

                  Posté par  . Évalué à 4.

                  > NéanmoinsMark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE.

                  Mais je pene qu'il a tord :-)
                  En tout cas aujourd'hui.

                  > Le récent billet de Mark S. est suffisamment explicite à ce sujet.

                  On peut aussi dire qu'il est implicite dans LTS != RHEL :-)
                  Cette sorte d'"appel au secours" le montre.

                  Je suis d'accord, il y a ambiguïté. Commerciallement Canonical veut chasser chez RHEL/SLES, mais techniquement/support/doc/etc ça ne le fait pas.

                  Si on met en concurrence Ubuntu LTS avec RHEL ou SLES, alors Ubuntu LTS est naze.

                  Juste un exemple, la doc :
                  Ubuntu : https://help.ubuntu.com/8.04/serverguide/C/index.html
                  RHEL : http://www.redhat.com/docs/manuals/enterprise/

                  Pas de ppc64, pas de s390, pas de ia64.

                  Il y a un monde entre les deux.
                • [^] # Re: firefow 3.0 beta 5

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

                  Néanmoins Mark Shuttleworth et Canonical n'hésitent pas à comparer Ubuntu LTS à RHEL ou Novell SuSE.

                  Oui enfin, c'est du marketing, hein. Personne n'est dupe, sauf les daicïdeur pressés.

                  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: firefow 3.0 beta 5

        Posté par  . Évalué à -4.

        Une bourde ?

        Et insérer une version morte au bout de 8 mois, dans une version destinée à vivre 3 années, c'est quoi ?

        Réfléchis un peu au lieu de poster de telles incongruités.
        • [^] # Re: firefow 3.0 beta 5

          Posté par  . Évalué à 6.

          Heureusement que tu n'utilises pas Debian Stable.
          • [^] # Re: firefow 3.0 beta 5

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

            Oui, heureusement ... je ne le supporterais pas.
            • [^] # Re: firefow 3.0 beta 5

              Posté par  . Évalué à -3.

              N'importe quoi ce que tu dis ! Mais vraiment nawak.

              Tu a déjà vue mamie Darveau qui t'appel parceque le ubuntu que son petit fils lui à installer ne boot plus depuis la derniere mise à jour, et qu'en plus windows est tellement vérolé qu'elle ne peut même plus aller sur le net ?
              Et oui mamie simone a cliqué sur mettre à jour, et hop un jolie kernel panic. Heureusement que c'est une geek mamie jte jure :) Ha bein non en fait elle à dut payer pour ce faire dépanner.

              Donc bon c'est peut être facile à installer toussa mais bof quoi, je préfere une distrib qui prends son temps moi, c'est plus sur.

              C'est comme ma femme, t'imagine si je me marié au bout d'une semaine ...

              Allez tous vous faire spéculer.

    • [^] # Re: firefow 3.0 beta 5

      Posté par  . Évalué à 6.

      que je sache, fedora n'a jamais prétendu être une distribution pour le grand public, ni pour les entreprises mais un laboratoire pour la RHEL (d'ailleurs je trouve ça abhérant que certains hébergeurs proposent encore la fedora au lieu de CENTOS qui n'est rien d'autre qu'une RHEL gratuite et maintenue 7 ans)

      Aucune publicité n'est apparu, et même RH ne fait pas de stand à son effigie. (seule la communauté daigne en parler)

      ET pourtant elle est bien plus stable en intégrant certains bêtas qui sont certes désagréable mais qui ne font pas freezé le tout en permanence comme certaines distributions qui prétendent être pour les professionnels et le grand public alors que c'est buggé de partout.

      Pour mieux profiter d'une fedora, il vaut mieux attendre 1 à 2 mois après sa sortie, on profite des mises à jour qui corrigent la plupart des soucis qui arrivent après une sortie. (sachant que chaque release sort tous les 6 mois environ, ce qui explique la non prétention de la distri à ne pas vouloir être la plus stable des stables avec tous les packages).

      Perso, je viens juste d'updater mon système de la 7 à la 8 (via yum), je n'ai eu aucun soucis. J'attendrais que la 9 soit plus "figée"

      Et puis si la 9 rebute, c'est pas grave y'aura la 10 bientôt :D
      • [^] # Re: firefow 3.0 beta 5

        Posté par  . Évalué à 8.

        > Aucune publicité n'est apparu, et même RH ne fait pas de stand à son effigie. (seule la communauté daigne en parler)

        Oui et non.
        Red Hat *vend* pour des entreprises. Red Hat *vend* RHEL, JBoss, des services, etc.
        Lorsqu'il y a une rencontre Red Hat (summit), c'est pour les clients Red Hat.
        Ce n'est pas du dédain, c'est une clarificaiton de la communication.
        Ce n'est pas une volonté de "cacher" Fedora. Sur la page d'accueil de http://www.redhat.com/ , il y a en titre la sortie de F9. Il y a aussi un lien vers http://fedoraproject.org/ sur toutes les pages de http://www.redhat.com/ .
        On trouve de nombreux articles sur Fedora dans Red Hat Magazine :
        http://www.redhatmagazine.com/
        Fedora : 53
        RHEL : 35
        Le prochain Red Hat Summit aura lieu en même temps avec FUDcon (et au même lieu :-)).

        Certe, il n'y a pas de publicité. On peut imaginer la raison.
        Red Hat préfère investir en développement qu'en pub. De plus, Red Hat ne vend pas Fedora. Donc investir en publicité sur Fedora ne lui fait rien gagner. Perso, je préfère que l'argent soit mis dans le développement (code, infrastructure pour la communauté, etc).

        Notons que Fedora veut son indépendance par rapport à la "stratégie commerciale ou communication" de Red Hat.
        Red Hat ne peut l'offrir totalement, mais y répond grandement (ce qui a des conséquences en bien et en mal).
        Si Red Hat ne se met pas en avant pour Fedora, c'est aussi car Fedora ce n'est pas que Red Hat. Red Hat ne peut pas s'"approprier" Fedora. C'est "seulement" le plus gros contributeur (mais un peu plus pour être honnète).
        http://www.redhat.com/archives/fedora-announce-list/2008-May(...)
        Giving credit where credit is due, and working hand-in-hand with others
        Tu ne peux donc pas être "agressif" et t'afficher en concurrent (comme le fait RHEL par exemple).

        Notons que le leader du projet Fedora n'est pas un employé Red Hat et que Red Hat n'a plus la majorité dans le directoire Fedora (4 sièges pour Red Hat sur 9).
        Notons aussi que Fedora n'a quasiment aucune pub pour Red Hat :-)
        On me rétorquera que c'est inutile...
        • [^] # Re: firefow 3.0 beta 5

          Posté par  . Évalué à 4.

          +1

          Fedora a son propre projet marketing, RedHat nous alloue un budget conséquent (géré par Paul Frields FedoraProject Leader), des Community Manager chargé en autre de la communication (comme Rahul Sundaram et bien d'autres), un Community Manager dédié au marketing (Jack Aboutboul). Sans compter la présence d'un artiste professionnel pour superviser l'équipe artistique.
          L'ancien FedoraProject Leader Max Spevack devrait s'occuper plus spécifiquement de la zone EMEA (construction d'un Fedora Europe sur l'impulsion des ambassadeurs locaux, d'une boutique européenne) et coordonner les principaux événements.

          RedHat a cédé la direction effective du projet à la communauté, ils nous donnent déjà du pognon, des ressources pour assurer la promo, on va pas leur demander d'en rajouter.
          ça nous donne un peu plus d'indépendance, comme pouvoir partager des espaces avec des copains comme CentOS, de ne pas se déguiser en vendeur costume 2 pièces cravate incluse pour RedHat.
          De notre côté, on fait la promo de FedoraProject et uniquement de FedoraProject.
        • [^] # Re: firefow 3.0 beta 5

          Posté par  . Évalué à 3.

          ça je te l'accorde entièrement !

          La publicité n'est pas utile :)

          les magazines le font à notre place et le bouche à oreille marche très bien

          dommage que la communauté ne soit pas très grande en France -_-
          • [^] # Re: firefow 3.0 beta 5

            Posté par  . Évalué à 2.

            On commence à être plus efficace, on a des bonnes relations avec les LUGs et les installs party sont régulièrement organisés.
            Sur Lyon, on a lancé les réunions entre Fedoristas, on retrouve aujourd'hui la même chose sur Paris et ailleurs. D'ailleurs nos collègues parisiens ont enrichi le concept en l'associant à un blog dédié, idée que l'on a récupéré par la suite.
            Au niveau européen, les ambassadeurs francophones ont été représentés lors des diverses réunions au sujet de la création Fedora Europe/EMEA.
            Le travail de la communauté francophone est reconnu à sa juste valeur dans la communauté Fedora, nous avons créé la première structure locale regroupant utilisateurs et contributeurs, nous avons un projet documentation cohérent, une boutique.
            On essaie également d'encourager l'écriture d'articles (si vous cherchez des auteurs, des relecteurs, passez nous voir sur irc ou contactez-nous par mail)
  • # Modesetting *dans le noyau*

    Posté par  . Évalué à 6.

    > Fedora introduit la gestion optionnelle du modsetting pour les cartes Intel !

    Le modesetting tout court, ca existe depuis des lustres pour plein de cartes (sinon tu ne pourrais pas avoir de X du tout).

    C'est le modesetting *dans le noyau* qui est important ici, ca permet d'éviter de changer de mode plusieurs fois pendant le boot. L'idée est que le noyau met la carte dans le bon mode (résolution+rafraichissement) des le debut du boot pour eviter d'avoir a rechanger plus tard (changer de mode = ecran qui saute et devient noir quelques secondes, donc pas beau et lent).
  • # ppc et ppc64 !

    Posté par  . Évalué à 3.

    Damned, il n'est pas dit dans l'annonce que Fedora marche sur i386 et x86_64.
    Certe, comme tout le monde.
    Mais ppc et ppc64 fait aussi parti des architectures supportées.

    En passant, F9 n'installe plus les librairies 32 bits et 64 bits en parallèle par défaut.
    On peut toujours les installer à la main.

    Côté SeLinux, notons que les utilisateurs commencent à être "confinés".
    Plus d'info ici :
    http://www.redhatmagazine.com/2008/04/17/fedora-9-and-summit(...)

    La police "targeted" n'est plus si "targeted".
    • [^] # Re: ppc et ppc64 !

      Posté par  . Évalué à 3.

      On va retrouver l'erreur un peu partout.
      Cette fois-ci, on s'est pris à la bourre pour écrire les annonces (il y a 2 versions), d'ailleurs je t'invite à la rédaction des annonces pour Fedora 10 si tu en as le temps (ça se passe sur la mailing-list fedora-fr), on aurait besoins de bons yeux comme les tiens ne serait-ce que pour relire le contenu. :)

      > Côté SeLinux, notons que les utilisateurs commencent à être "confinés".
      Xguest aurait effectivement pu avoir sa place dans l'annonce. ça fait partie des aspects méconnus de Fedora qui gagnerait à être mis en valeur.
      • [^] # Re: ppc et ppc64 !

        Posté par  . Évalué à 2.

        > Xguest aurait effectivement pu avoir sa place dans l'annonce.

        J'avais fait la remarque pour montrer que SeLinux progresse. Il n'était pas un atout pour le desktop, ça pourrait changer.

        Une annonce est un compromis, on ne peut pas tout y mettre.
  • # Oui mais ...

    Posté par  . Évalué à 2.

    Il y a actuellement un vilain bug de Dbus avec les disques dur SAMSUNG.

    Ce constructeur a donné un nom finissant avec un '/' à un certain nombre de ses modèles, cela provoque un crash de Dbus au tout début de l'installation...

    exemple :
    ValueError: Invalid object path '/org/freedesktop/Hal/devices/storage_model_SAMSUNG_HD160JJ/': ends with '/' and is not just '/'
    install exited abnormally [1/1]

    A l'heure actuelle le bug est reconnu mais pas encore fixé, si vous avec une machine avec un disque SAMSUNG vous risque de ne pas pouvoir installer, voire avoir des problèmes apres avoir lancé une MAJ.

Suivre le flux des commentaires

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