Sortie de la bêta de Fedora 14 Laughlin

Posté par  . Modéré par tuiu pol.
Étiquettes :
24
28
sept.
2010
Fedora
La bêta est une étape importante dans le développement de Fedora, c'est à ce moment-là que les fonctionnalités présentes dans la version finale sont figées, seules les anomalies critiques sont corrigées. Nous vous invitons à télécharger, installer et tester cette bêta afin de nous aider à faire de Fedora 14 une version solide.

Bien évidemment des anomalies connues subsistent et vous pourrez les retrouver sur la page tenue à ce propos sur le wiki. Si vous rencontrez une anomalie non répertoriée sur cette page, nous vous encourageons à la signaler auprès de https://bugzilla.redhat.com, notre système de suivi d'anomalies.

Vous pourrez télécharger Fedora 14 bêta à cette adresse : http://fedoraproject.org/fr/get-prerelease Les nouveautés !

Un des faits marquants est le report à F-15 de systemd en tant que système d'init par défaut, ce dernier restant au stade d'avant première technologique.

Nouveautés pour les utilisateurs

Les bureaux disponibles sont GNOME 2.32 (GNOME 3.0 étant reporté à mars 2011), KDE 4.5 SC, XFCE 4.6.2, LXDE et MeeGo 1.0.

Vous profiterez de la nouvelle libjpeg-turbo qui optimise le chargement et la sauvegarde des images au format JPEG tout en restant compatible avec la libjpeg originale. Les machines récentes verront les temps de chargement divisés par deux et même les plus anciennes connaîtront une légère amélioration.

C'est également la première distribution incluant SPICE, le protocole d'affichage distant destiné aux environnements virtualisés (à ne pas confondre avec SPICE, le simulateur de circuit électronique). Actuellement, seule la solution de virtualisation qemu-kvm est prise en charge. SPICE a été créé par la société Qumranet (déjà à l'origine de KVM) et fut libéré en 2009 par Red Hat suite au rachat de Qumranet en 2008.

Par rapport au protocole VNC, SPICE apporte :
  • La prise en charge native du chiffrement ;
  • La prise en charge du streaming vidéo ;
  • L'adaptation dynamique de la bande passante ;
  • La prise en charge des moniteurs multiples ;
  • La prise en charge des flux audio bidirectionnels ;
  • La prise en charge d'algorithmes spécialisés de compression d'images.

Les fonctionnalités en cours de développement sont:
  • Le partage de réseau ;
  • Le partage du presse-papier ;
  • Le partage des périphériques USB (le serveur aura accès aux périphériques disponibles sur le client).

et bien d'autres choses encore !

Des clients linux et windows sont disponibles ainsi que des pilotes pour les systèmes invités Microsoft Windows.

Nouveautés pour les administrateurs

Les utilisateurs de la plate-forme de cloud computing d'Amazon EC2 disposeront d'une image réactualisée basée sur Fedora 14 (la dernière image disponible étant basée sur Fedora 8).

Les administrateurs apprécieront également la disponibilité d'ipmiutil un client IPMI plus accessible.

Nouveautés pour les développeurs

Les environnements de développement Eclipse et Netbeans passent respectivement en version 3.6 et 6.9.

GDB s'offre une nouvelle commande "heap" permettant de surveiller la mémoire allouée dynamiquement, fonctionnalité développée par David Malcolm.

Python passe en version 2.7. L'environnement Python 3 quant à lui continue de s'étoffer notamment avec la disponibilité de PyQt4.

Qt passe en version 4.7. Notons l'introduction de PySide, les bindings Python développés par Nokia sous licence LGPL. L'environnement GNUStep est également introduit.

Fedora 14 sera livré avec un environnement de développement D complet composé du compilateur LDC basé sur l'infrastructure LLVM (actuellement, le compilateur D libre le plus actif), de la bibliothèque standard Tango et divers composants logiciels très utiles. Merci à Jonathan Mercier pour l'énorme travail d'intégration, un contributeur Fedora biendechénou (cocoricooo !).

Divers

Fedora 14 verra également le retour de l'architecture secondaire s390 qui n'avait pas été mise à jour depuis Fedora Core 6.

Bien que ça n'ait aucun rapport direct avec la béta, je signale l'existence des dépôts Fedora People permettant aux contributeurs de maintenir un dépôt personnel tout en profitant de l'infrastructure fedoraproject.org :
http://repos.fedorapeople.org/

Rendez-vous pour la version finale prévue début novembre !

Aller plus loin

  • # Typos &Co

    Posté par  . Évalué à 2.


    https://bugzilla.redhat.com">notre système de suivi d'anomalies.

    avec comme url
    https://linuxfr.org/submit/%3Ca%20href=



    et mêmes les plus ancienne

    même est un adverbe ici
    http://francite.net/education/cyberprof/page111.html



    les bindings Python développés par Nokia sous licence LGPL. L'environnement GNUStep est également introduit.

  • # ppa like?

    Posté par  . Évalué à 1.

    Ton dernier point c'est le meme style que la ferme de build de opensuse et les ppa de ubuntu? Comme pas mal de linuxien aiment bien vivre dangereusement avec la derniere version installe cela peut etre tres bien pour la popularite de fedora.

    • [^] # Re: ppa like?

      Posté par  . Évalué à 3.

      > Ton dernier point c'est le meme style que la ferme de build de opensuse et les ppa de ubuntu?

      Oui, c'est ça. Les développeurs Fedora ont maintenant la possibilité de proposer des applications qu'ils ne peuvent pas mettre dans le dépôt officiel (on parle déjà d'en créer un pour postgresql 9, qui est sortie après le freeze de Fedora 14).

    • [^] # Re: ppa like?

      Posté par  . Évalué à 3.

      C'est un poil plus rustique que les ppa ou l'Open Build Service, les contributeurs ont accès au service de build Koji pour construire les paquets (et éventuellement des machines de tests pour les architectures "exotiques") mais la création du dépôt sur leur espace fedorapeople reste en partie artisanale.
      À terme, le projet COPR (Cool Other Packages Repositories) devrait permettre d'intégrer ce genre de fonctionnalités directement via le service de build Koji et d'avoir des utilitaires plus chiadés.

    • [^] # Re: ppa like?

      Posté par  . Évalué à 1.

      Oui, mais et la sécurité?

      Je veux dire, n'importe qui peut mettre en place un de ces dépôts ou c'est aussi surveillé que les paquets présents dans les dépôts officiels?

      • [^] # Re: ppa like?

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

        C'est tout l'avantage d'OBS, Koji ou PPA : on n'a pas besoin d'un tampon "validé" pour pouvoir fournir quelque chose à l'utilisateur.

        Après, chacun est libre de choisir : faire confiance uniquement aux mainteneurs de la distro et refuser (sans vouloir être péjoratif : tout dépends de la sécurité que tu veux) la confiance du développeur du logiciel qui t’intéresse, ou aussi faire confiance dans le développeur du logiciel qui t’intéresse.

        La chose importante à retenir du système est : tu as le choix (nombre et version à jour des logiciels contre vérification par un tiers de confiance).

      • [^] # Re: ppa like?

        Posté par  . Évalué à 4.

        > n'importe qui peut mettre en place un de ces dépôts

        Non, ça implique que tu sois un contributeur Fedora (donc avoir accepté le CLA) et avoir accès au système de build (donc faire partie du groupe des mainteneurs).

        > c'est aussi surveillé que les paquets présents dans les dépôts officiels?

        Les paquets sont sous la responsabilité des mainteneurs, la seule restriction est que les paquets doivent respecter les guidelines Fedora (gage de qualité et d'intégrité libriste). La plupart du temps, les dépôts fedorapeople sont maintenus par le mainteneur des paquets dans la distribution ou un mainteneur expérimenté (je citerais l'exemple de remi et spot qui maintiennent respectivement les dépôts remi - LAMP- et Chromium).
        C'est exactement le même problème avec les PPA et l'OBS, mais certains réfléchissent déjà à l'intégration de la QA dans COPR qui permettra d'automatiser entièrement la gestion des dépôts fedorapeople. Entre parenthèses, Fedora travaille sur un framework de tests qualité automatisés aka autoqa qui permet de lancer des tests lorsqu'un paquet est construit, soumis en tant que mise à jour etc ... Si COPR est un jour incorporé dans Koji, les dépôts fedorapeople en bénéficieront automatiquement (yakafokon en somme :o) )

    • [^] # Re: ppa like?

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

      Oui, Koji (pour Fedora) est dans la même veine que PPA. Avec le même défaut que PPA d'ailleurs : limité à une distro spécifique (donc faut uploader ta MAJ sur PPA, puis Koji etc...).
      C'est mieux que rien, mais je reste personnellement bloqué sur OBS pour deux raisons : c'est simple, et multi-distros (CentOS/Debian/Ubuntu/Suse/Fedora/Mandriva), et ça c'est très agréable. Si OBS n'existait pas, j'aurai trouvé l'initiative Koji très bonne, mais maintenant avec OBS qui milite pour une facilité de création de paquets pour plein de distros dont Fedora...

      • [^] # Re: ppa like?

        Posté par  . Évalué à 5.

        Je suis d'accord avec toi pour dire qu'OBS est un excellent service mais c'est destiné principalement aux développeurs qui veulent fournir des paquets binaires pour différentes distros - ce qui est justement ton cas - sans devoir maintenir un gazillion de machines de builds (virtuelles ou non).
        Néanmoins, ça n'est pas un outil adéquat pour gérer un dépôt ou même une distro, tu perds l'intégration (pour reprendre l'exemple des init vu plus loin, un mainteneur upstream fournira un script sysV générique mais pas le job upstart ou l'unit systemd), les recettes deviennent rapidement fouillies pour gérer les différents cas, etc ...


        Je tiens à souligner que Koji permet de construire des paquets pour TOUTES les distributions RPM. La gestion des dépendances étant fournie par yum, pour supporter une nouvelle distro, il suffit de générer les méta-données yum (à la base, c'est un format commun avec apt/rpm et smart) et de fournir un fichier de configuration avec l'adresses des mirroirs.
        Après, fp.o n'a pas les ressources pour ouvrir son propre build service multi-distro RPM mais les outils sont libres, l'installation est pas trop compliquée. J'ai ouï dire que koji est en cours de packaging dans Debian (celà-dit mock l'utilitaire de chroot l'est depuis quelques années et permet de construire des paquets fedora conformes depuis debian ;-) )

        • [^] # Re: ppa like?

          Posté par  . Évalué à 4.

          ça n'est pas un outil adéquat pour gérer un dépôt ou même une distro
          Tu peux préciser ce que tu entends par là?

          • [^] # Re: ppa like?

            Posté par  . Évalué à 4.

            Par exemple, pour construire les paquets, OBS utilise un environnement générique pour le chroot, les mises à jours ne sont pas récupérés automatiquement, ça n'aide pas à détecter les dépendances de compilations explicites (ie: c'est une des raisons pour laquelle debian et fedora utilisent des chroots minimalistes).
            Plus prosaïquement, les recettes sont rapidement remplie d'instructions conditionnelles pour gérer les différences entre les distros, les paquets sont le plus génériques possible donc pas parfaitement adapté à la distributions, ils ne sont pas forcément compilés avec les mêmes flags etc ...

            Bien sûr, on peut utiliser OBS pour gérer une distro mais tu perds l'avantage principal du service: rendre accessible aux développeurs la construction de paquets pour diverses cibles.

            • [^] # Re: ppa like?

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

              De souvenir, il y a une façon de faire pour avoir un spec file par distro, ce qui permet de te faire la main sur tes machines virtuelles qui vont bien pour faire l'intégration, et OBS permet ensuite d'automatiser les version suivantes tout en ayant 100% des spécificités de chaque distro et/ou version de distro.

              Je ne vois donc pas du tout ce qu'on perd avec OBS par rapport à d'autres solutions, y compris au niveau intégration (=il faut toujours se taper l'intégration des trucs spécifiques à chaque ditro, mais une fois que c'est fait, OBS automatise les besoin récurents comme la mise à jour d'une appli).

              Bref, on perd rien avec OBS (si l'intégration est faite, on la reprend, si elle est pas faite, ben elle est pas faite), on ne fait que gagner des choses (l'automatisation pour chaque mise à jour d'une appli), ou alors montre-moi plus précisément ce que tu penses perdre comme "intégration" que tu ne peux pas mettre dans les spec files d'OBS.

  • # Bureaux disponibles

    Posté par  . Évalué à 3.

    Ah bon, GNOME 2.32 est sorti ?

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Bureaux disponibles

      Posté par  . Évalué à 5.

      L'image a été composée il y a deux semaines juste avant la release candidate, donc à l'installation tu te retrouveras avec plus ou moins la dernière béta. En revanche, la release candidate d'ors et déjà disponible dans les mises à jours.

      La version finale de GNOME 2.32 est prévue pour demain par ailleurs.

  • # SPICE

    Posté par  . Évalué à 2.

    SPICE à l'aire intéressant.

    /me a deux questions:

    - Permet-il de ne récupérer que les images des fenêtres de l'OS invité afin de les intégrer dans le bureau de l'OS où se trouve le client SPICE? (comme dans Virtualbox)

    - Faudra-il un client spécial ou SPICE sera intégré dans Virt-Manager?

    • [^] # Re: SPICE

      Posté par  . Évalué à 3.

      -non, cela fait partie des RFE, mais n'a pas la priorité des développeurs (c'est en effet pas évident à faire...)
      -Pour l'instant il faut un client spécial pour avoir l'accélération (package spice-client), mais à noter que l'interface QXL (carte vidéo émulée) est compatible avec les deux flux (Spice et standard), ainsi dans Virt-manager tu peux voir l'écran et interagir avec, mais sans l'accélération QXL, l'audio, etc... Le développement d'un widget GTK pour integration dans virt-manager est prévue.

      • [^] # Re: SPICE

        Posté par  . Évalué à 1.

        Cool, merci de ta réponse. :D

        J'ai hâte de tester dans Virt-Manager. (Par ce que pour le moment, l'audio ça fonctionne pas)

  • # systemd / upstart

    Posté par  . Évalué à 2.

    Quels sont les avantages / inconvénients de systemd par rapport à l'upstart d'ubuntu ?

    • [^] # Re: systemd / upstart

      Posté par  . Évalué à 9.

      Systemd se rapproche beaucoup de launchd (l'init d'Apple sous licence Apache), pour définir un service, on n'écrit plus un script shell mais un simple fichier de configuration (un format .ini like), donc on se débarasse de l'overhead lié au lancement d'un shell pour exécuter le job (upstart)/unit (systemd).
      De plus, systemd est beaucoup plus aggressif qu'upstart pour la parallélisation des tâches et le lancement de services à la demande. Sous Fedora qui utilise encore des scripts d'init sysV, le démarrage est beaucoup plus rapide qu'avec upstart. Pour être honnête, il faudrait pouvoir utiliser les deux inits en utilisant des scripts/fichiers de configuration au format natif pour les différencier à ce niveau.

      Par exemple, l'intégration de D-Bus dans systemd permet de parallèliser le lancement de services: si un service A requiert que le service B soit actif, plus besoin d'attendre que B soit lancé pour démarrer A, systemd s'arrange pour que D-Bus place les requêtes de A dans une file d'attente le temps que B ait fini de se lancer.

      Systemd est assez bien fourni en outils d'administration (ligne de commande ou graphique) qui permettent de suivre l'état des processus (grâce à l'api cgroups du noyau linux entre autre).

      Tu trouveras pas mal d'informations sur ce billet de Lennart:
      http://0pointer.de/blog/projects/systemd.html

      • [^] # Re: systemd / upstart

        Posté par  . Évalué à 3.

        que du bon en somme, merci pour ces précisions

      • [^] # Re: systemd / upstart

        Posté par  . Évalué à 5.

        J'aime beaucoup systemd.
        C'est encore de l'excellent (et paradoxalement détesté par beaucoup) Lennard.

        Systemd se rapproche beaucoup de launchd (l'init d'Apple sous licence Apache), pour définir un service, on n'écrit plus un script shell mais un simple fichier de configuration (un format .ini like), donc on se débarasse de l'overhead lié au lancement d'un shell pour exécuter le job (upstart)/unit (systemd).

        Ça c'est pour les performances, je dois dire que ça me touche peu (booter en 20 ou 30 secondes je m'en fous).
        Par contre, ça va forcer la standardisation des services au-lieu que chaqu'un fasse comme bon lui semble. D'autres optimisations seront alors possibles.

        De plus, systemd est beaucoup plus aggressif qu'upstart pour la parallélisation des tâches

        systemd s'en fout de la parallélisation des tâches :-)
        C'est plus con et plus subtile que ça.

        systemd s'arrange pour que D-Bus place les requêtes de A dans une file d'attente le temps que B ait fini de se lancer.

        Pas vraiment. Systemd crée les "ports" d'écoute pour A et B et lance A et B.
        A "parle" à B et si B ne peut répondre (car il n'est pas encore initialisé), A attend (probablement bloqué dans l'appel système d'écriture à B).
        Il y a aussi un mode à la "inetd". systemd crée un port d'écoute pour B, tant que personne ne cause à B, systemd ne le lance pas.
        L'exemple typique est sshd. Pourquoi lancer au démarrage sshd ? Il faut le lancer quand on en a besoin, c'est ce que fait systemd.

        Systemd est assez bien fourni en outils d'administration (ligne de commande ou graphique) qui permettent de suivre l'état des processus (grâce à l'api cgroups du noyau linux entre autre).

        Avec cgroups, c'est surtout enfin fiable.

        systemd est vraiment la bonne réponse au problème. J'adore.
        Sûr il va y avoir des problèmes au début, mais c'est la voie à suivre.

        • [^] # Re: systemd / upstart

          Posté par  . Évalué à 2.

          « A "parle" à B et si B ne peut répondre (car il n'est pas encore initialisé), A attend (probablement bloqué dans l'appel système d'écriture à B). »

          Pas forcément, si A a vraiment besoin d'une réponse de B pour continuer, là oui.
          Mais si c'est un service qui envoi des messages à syslog, le service n'a pas besoin de réponse, donc il continue à s'exécuter. Et quand syslog sera lancé il lira ce qu'il y a sur la file d'attente.

  • # SPICE

    Posté par  . Évalué à 2.

    La technologie SPICE m'intéresse. De ce que j'ai compris, ca serait l'équivalent de MS Terminal Server. A mon niveau, je trouve que ce système TSE fonctionne bien, et j'ai toujours été déçu de ne pas avoir de vrai équivalent sur système Linux. Ca marche vraiment bien même à travers des lignes adsl basiques.

    Contrairement à l'affichage de VNC où c'est poussif. Et contrairement aussi à la transparence réseau de X qui est d'une lenteur inutilisable (plusieurs dizaines de secondes parfois pour ouvrir une application à distance).

    D'ailleurs, sans vouloir lancer de trolls, ca sert vraiment la transparence réseau de X ? Car pour moi, c'est inutilisable. Je me connecte en ssh sur une machine puis je lance en ligne de commande l'application graphique. Celle-ci met plusieurs dizaines de secondes avant de s'afficher. Et ensuite l'affichage à une latence énorme de plusieurs secondes. La même utilisation à travers un réseau 100Mb/s améliore un peu la chose par rapport à l'adsl mais c'est encore loin d'être utilisable. Je refais ce même test depuis plusieurs années sans amélioration.
    Je m'y prends mal ? Ce n'est pas fait pour ca ?

    • [^] # Re: SPICE

      Posté par  . Évalué à 5.

      Le problème n'est pas le débit, mais le "round-trip" : une application développée en faisant attention à ne pas faire d'aller-retour entre le serveur X et l'appli client s'exécutera très bien, même sur une ligne ADSL. Ce n'est malheureusement pas le cas de nombreuses applications (Firefox en est un exemple flagrant...). Je te conseille d'essayer la technologie NX en désactivant toutes les optimisations, sauf la suppression du round-trip, et tu seras surpris!! (J'ai déjà ouvert un bureau gnome à distance avec un ping de 250ms, sans avoir à préparer un café pour patienter...)
      Spice est bien différent, dans le sens où il est fait pour cela : il compresse (éventuellement) les images, et envoie les requètes lorsque nécessaire au client (qui, dans un futur proche, utilisera les fonctionnalités avancées de sa carte graphique pour effectuer le rendu plus rapidement). Donc Spice fonctionne très (très) bien sur de l'ADSL/250ms (testé et approuvé par moi-même).

      • [^] # Re: SPICE

        Posté par  . Évalué à 1.

        SPICE peut-il être utilisé sur une machine réelle plutôt que virtuel? Par exemple pouvoir se connecter en wifi au media-center et utiliser l'écran qui lui est branché dessus comme un second écran du Laptop en se basant sur SPICE pour le transport d'image et de son (un bon moyen d'avoir un équivalent libre au WIDI d'Intel).

        • [^] # Re: SPICE

          Posté par  . Évalué à 1.

          Il semblerait que ce soit prévu, mais pas dans un futur proche (cela implique d'ajouter un driver totalement virtuel au sein d'un OS existant, ce qui est relativement différent de l'ajout d'un driver + un device virtuel via qemu).
          Je pense que c'est relativement faisable néanmoins, mais le besoin n'est probablement pas aussi fort que celui d'un connexion broker opensource que Spice tente de combler!

    • [^] # Re: SPICE

      Posté par  . Évalué à 2.

      je trouve que ce système TSE fonctionne bien, et j'ai toujours été déçu de ne pas avoir de vrai équivalent sur système Linux

      On peut installer un serveur rdesktop sous Linux avec xrdp http://xrdp.sf.net ou utiliser NX de NoMachine, qui fonctionne plutôt bien.

      ca sert vraiment la transparence réseau de X?

      Oui et ça marche très bien. Le projet LTSP (et plein d'autres) est bâti avec. Tu peux essayer LTSP facilement et rapidement avec Ubuntu, Debian, OpenSuSE.

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

      • [^] # Re: SPICE

        Posté par  . Évalué à 1.

        NX nomachine

        L'efficacité de cette solution dépend de l'environnement de bureau.
        Dans mon cas, depuis l'arrivée de kde4, même avec la désactivation les effets de bureau, des temps de latence important sont apparus, inexistants sous kde 3.5 dans les mêmes conditions réseaux.
        J'ai cru comprendre que cela venait de la nouvelle manière qu'à kde d'utiliser le serveur X pour le rendu (ou un truc comme ça, j'y connais rien)

        • [^] # Re: SPICE

          Posté par  . Évalué à 2.

          [lenteur de kde4 en réseau] J'ai cru comprendre que cela venait de la nouvelle manière qu'à kde d'utiliser le serveur X pour le rendu

          A peu près. Ça vient des thèmes et de Qt, ce n'est pas tellement lié aux effets de bureau si j'ai bien compris. Ça peut s'arranger nettement avec Qt 4.7.
          On en a parlé un peu sur la liste LTSP.
          Denis Steck en a parlé dans 2 journaux ici même, regarde http://linuxfr.org/~steckdenis/30131.html (il y a un lien vers son premier journal)

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

          • [^] # Re: SPICE

            Posté par  . Évalué à 1.

            Oui, j'avais d'ailleurs lu ces journaux quand ils sont apparus.
            J'avais surtout retenu qu'il fallait patienter (pour Qt 4.7) et bien choisir son thème, certains étant à priori moins gourmand que d'autres.
            En accès direct, Kde ne me semble pas particulièrement lent sur mon pc. Ce n'est que pour les accès distant avec NX que ça me chagrine.

            • [^] # Re: SPICE

              Posté par  . Évalué à 2.

              Je viens de passer sous QT 4.7, et en local au moins ça déchire. Reste à tester en réseau et en accès distant.
              Mais je suis (naïvement) surpris que ce soit lent avec NX. Il devrait être au moins aussi rapide que VNC, non?

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

              • [^] # Re: SPICE

                Posté par  . Évalué à 1.

                Par rapport à VNC, je n'ai pas essayé depuis longtemps, le NX étant tellement plus confortable (du moins jusq'à maintenant).
                J'ai juste remarqué que par rapport à kde 3.5., c'était beaucoup plus lent. Pour dire, avec une connexion adsl free, je ne ressentais quasiment pas de latence en utilisant une session shadow (c'est à dire déjà ouverte localement) sous 3.5. Alors qu'avec kde 4.5, c'est du genre : clic sur le menu kde, 2-3 secondes d'attente et je vois le menu !
                Et encore, cela c'est très nettement amélioré par rapport aux premières versions de kde 4. Mais en local, aucun problème, c'est très réactif. D'ailleurs, je viens de regardé, j'utilise aussi Qt 4.7 (kde 4.5.68, mandriva cooker).
                Cela fait longtemps que je n'ai pas lancé de connexion NX (jamais avec Qt 4.7), n'en ayant que rarement besoin (la ligne de commande étant tout de même plus rapide). Peut être que c'est mieux maintenant. Je testerais demain depuis le boulot.

  • # Nouvelle version mais toujours ces trois icônes

    Posté par  . Évalué à 1.

    On a le droit à une nouvelle version, mais on a toujours ces 3 icônes (dossier de l'utilisateur, poste de travail et corbeille) sur le bureau de Gnome et qui sont des doublons de ce qu'on trouve sur les deux Gnome Panels. D'autant que les emplacements sûr les Gnome Panels sont plus souvent et plus rapidement accessible que les icônes du bureau.

    Mais personne chez Fedora ne semble savoir pourquoi ils sont toujours là.

    Une idée?
    C'est de la superstition?
    Du mysticisme?
    Du vodoo?

  • # Pas encore à jour ?

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

    Je ne sais pas si je passe par un miroir qui n'est pas encore bien à jour, mais je n'ai pas trouvé de liens directs pour récupérer les isos (tout pointe encore vers l'alpha).

    En revanche, les torrents sont dispos ici : http://torrent.fedoraproject.org/torrents/

    DVD x86_64 : http://torrent.fedoraproject.org/torrents/Fedora-14-Beta-x86(...)
    DVD i386 : http://torrent.fedoraproject.org/torrents/Fedora-14-Beta-i38(...)

    • [^] # Re: Pas encore à jour ?

      Posté par  . Évalué à 2.

      Bhas, passons par Torrent. C'est bien plus "Internent" et moins "Minitel" que le téléchargement direct.

  • # Pas beaucoup de nouvelles fonctionnalités

    Posté par  . Évalué à 1.

    Il y a un truc qui m'étonne, c'est le peut de nouvelles fonctionnalités par rapport aux anciennes version de Fedora. Est-ce dut au fait que tout le monde se concentre sur Gnome 3 ou est-ce une baisse d'intérêt des développeur?

    • [^] # Re: Pas beaucoup de nouvelles fonctionnalités

      Posté par  . Évalué à 2.

      Tu trouveras quelque détails ici :
      http://fedoraproject.org/wiki/Releases/14/FeatureList
      Cela peut paraître en effet assez peu, surtout pour l'utilisateur final. Je pense que cette release est assez orienté développeurs.
      D'un autre coté, l'intérêt des release régulières à dates quasi-fixes (comme Ubuntu mais pas comme Debian), c'est de proposer aux utilisateurs une distribution complète, fonctionnant "out-of-the box", et avec l'état de l'art des gros paquets (je pense à Gnome, KDE, etc...). Cela permet d'uniformiser un peu les versions que l'on va trouver d'un ordinateur à l'autre.
      Personnellement, j'utilise beaucoup toutes les fonctionnalités de virtualisation, et j'attendais depuis un bon moment cette F14 : pour Spice, mais aussi pour quelques nouvelles fonctionnalités de qemu, virt-manager, etc... (jusque là j'ajoutais le dépot "rawvirt" pour en profiter).

      • [^] # aa

        Posté par  . Évalué à 0.

        Je suis aussi un amateur de virtualisation. Pourrait-tu m'en dire un peut plus sur les nouveautés de Qemu, Virt-Manager, et Libvirt qu'il y aura pour F14?

        • [^] # Re: aa

          Posté par  . Évalué à 1.

          Je ne sais pas ce qui en particulier atterrit dans F14 (puisque je les ai au fur et à mesure par le dépot rawvirt), mais pas mal d'améliorations sur la couche réseau pour qemu+kvm (vhostnet : http://fedoraproject.org/wiki/Features/VHostNet ), beaucoup de corrections de bogues tant du coté de libvirt que de virt-manager, et une meilleure gestion des pools de disques et des réseaux dans virt-manager (gestion des réseau initiée depuis F13 d'ailleurs).

    • [^] # Re: Pas beaucoup de nouvelles fonctionnalités

      Posté par  . Évalué à 1.

      Il y a, me semble t-il, beaucoup de travail upstream dans GNOME. Pour ne citer qu'un exemple, les méta-contacts dans Empathy, l'amélioration de la vidéo-conférence dans Telepathy (fonctionnelle même sur MSN !), tout le travail de nettoyage en vue de GNOME 3, et sûrement plein d'autres choses que j'oublie sur le moment...

  • # Language D

    Posté par  . Évalué à 1.

    Bonne nouvelle, c'est toujours agréable de pouvoir installer un environnement en automatique.

    Celà veut-il dire que le language D va prendre de l'importance dans le développement de Fedora ?
    Ou est-ce simplement un développeur qui s'est fait plaisir ?

    • [^] # Re: Language D

      Posté par  . Évalué à 3.

      Réponse 2, si tu es intéressé le mainteneur a écrit une série d'articles sur la programmation en D (en anglais et en français):
      http://blog.fedora-fr.org/bioinfornatics/

      La très grande majorité des développements propres à Fedora se font en Python, les infrastructures web utilisent principalement le framework TurboGears (à l'exception notable de Transifex qui utilise aujourd'hui Django mais ce n'est plus à proprement parler un projet Fedora)

      • [^] # Re: Langage D (D programming)

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

        Je me suis fait plaisir :)
        Il n'est pas possible de réécrire l'existant en D, le python remplit très bien ses missions. L'ajout du langage D et pour se tourner vers l'avenir et mettre à disposition des développeurs des outils pour travailler dans ce langage.
        J'ai travailler upstream dans la philosophie de fedora par conséquent le travail sera profitable à tout le monde.
        Pour une personnes ayant fait un des langages suivant: C++, Java, Python, Ruby
        J'estime à un mois le temps d'être opérationnelle afin d'apprendre l'API. Par la suite la productivité est proche de ce qui est fait avec Python.
        Bonne continuation

  • # Systemd

    Posté par  . Évalué à 4.

    En tout cas, si Systemd n'est pas dans Fedora, il est diponible dans Debian.
    Certes, c'est dans experimental, mais on peut parfaitement l'installer et même l'utiliser.

    En plus, il ne casse pas le système, puisque si on veut l'utiliser, il suffit de l'appeler au boot avec init=/bin/systemd . SysV n'est pas du tout impacté.

    Je viens juste de faire le test : pour l'instant je ne trouve pas que c'est transcendant, c'est un poil plus rapide, mais en tout cas la doc est alléchante (cf sur http://0pointer.de/public/systemd-man/systemctl.html et surtout http://www.freedesktop.org/wiki/Software/systemd/TipsAndTric(...) ).

    Bref, entre Systemd et Plymouth pour l'esthétique, je crois que Linux n'a plus à rougir de son processus de démarrage.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Systemd

      Posté par  . Évalué à 4.

      Je viens juste de faire le test : pour l'instant je ne trouve pas que c'est transcendant, c'est un poil plus rapide

      C'est sans doute dû au fait qu'il utilise les anciens scripts de SysV au lieu des fichiers de conf spécifiques. Il va falloir qui entre dans testing sans doute pour que la plupart des services soit portés.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Systemd

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

      > En tout cas, si Systemd n'est pas dans Fedora

      Il est dans Fedora, il n'est juste pas par défaut. Mais si on veut on peut l'utiliser, il suffit d'installer le paquet systemd-sysvinit.

Suivre le flux des commentaires

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