Fedora 14 en version alpha

Posté par  . Modéré par patrick_g.
Étiquettes :
21
26
août
2010
Fedora
La nouvelle version de Fedora se prépare et déjà, la version alpha de la future Fedora 14 est disponible. De son petit nom "Laughlin", elle est prévue pour sortir vers novembre 2010, une bêta est quant-à-elle prévue pour fin septembre.

Cette nouvelle version sera l'occasion pour les utilisateurs de Fedora de bénéficier d'un noyau 2.6.35 et de nombreuses nouvelles fonctionnalités et mises à jour de programmes existants. Depuis peu, la version alpha de la future Fedora 14 est disponible. Cette nouvelle version incorporera :
  • Un noyau Linux 2.6.35
  • La version 4.5 du bureau KDE
  • Sugar 0.9, un environnement de bureau écrit en Python
  • L'environnement GNUstep
  • L'implémentation d'un nouveau langage: D
  • Python 2.7
  • Perl 5.12
  • La prise en charge de Perl 6 avec Rakudo
  • Erlang R14
  • Netbeans 6.9, nouvelle version de l'environnement de développement intégré Netbeans
  • Remplacement de upstart par systemd, nouveau gestionnaire de session plus rapide et efficace
  • Une compression/décompression plus rapide du format JPEG avec la librairie libjeg-turbo pour de nombreuses applications
  • De meilleurs outils de développement avec Gdb index qui booste Gdb, et les nouvelles versions de Netbean et Eclipse
  • L'architecture de MeeGo 1.0 sur Fedora
  • EC2 amenant le cloud computing d'Amazon (Amazon Elastic Compute Cloud)
  • ipmiutil, un utilitaire permettant aux administrateurs d'utiliser les fonctions de l'interface IPMI (Interface de gestion intelligente de matériel) sans difficultés
  • Ajout de open SCAP (Security Content Automation Protocol), permettant aux utilisateurs de vérifier si leur système est conforme à une configuration de sécurité définie
  • Introduction de Spice comme solution d'interaction avec les bureaux virtuels
  • Memory Debugging Tools, de nouvelle commande au debugger gdb pour permettre de traquer et résoudre les problème d'utilisation excessive de la mémoire au sein des programmes et librairies
  • Boost 1.44
  • ROOT, un logiciel de simulation, d'acquisition et d'analyse de données développé par le CERN.

Comment s'essayer à la version alpha ?
En la téléchargeant ici via bittorrent et là sur les miroirs.

Fedora 14 est prévue pour sortie à partir de novembre 2010 (bêta vers fin septembre).

Aller plus loin

  • # SPICE ?

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

    Je crois que le Spice dont on parle ne sert pas à simuler des circuits électriques, mais ressemble plus à un VNC/RDP amélioré: http://www.redhat.com/virtualization/rhev/desktop/spice/
    • [^] # Re: SPICE ?

      Posté par  . Évalué à 3.

      Oups, ma faute... Merci beaucoup.

      Pour Spice aussi : [http://www.spice-space.org/home.html]
    • [^] # Re: SPICE ?

      Posté par  . Évalué à 0.

      Oui.
      L'arrivée de Spice dans une distribution (plus ou moins) communautaire est à saluer. C'est un élément très important d'une bonne offre de virtualisation.
      Le code était dispo (il est dans RHEL), mais personne le portait ailleurs.
      Il a encore fallu que Red Hat fasse le job...
  • # Systemd

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

    J'ai hâte de tester la nouvelle fedora pour voir systemd. Il a l'air pas mal.

    Lors de sa publication, Lennart n'a pas arrêté de répéter que ce n'était pas parce qu'il travaillait sur systemd qu'il allait être intégré à Fedora, mais finalement, peut être que si.

    J'invite tout le monde à lire son blog si ce n'est déjà fait, ce qu'il à créé est très astucieux:
    http://www.freedesktop.org/wiki/Software/systemd
    • [^] # Re: Systemd

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

      De son blog: http://0pointer.de/blog/projects/systemd-update.html

      We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself. Most of this will not be enabled in F14 however, even though it is shipped with systemd upstream. With this enabled the entire Linux system gains a completely new feeling as the number of shells we spawn approaches zero, and the PID of the first user terminal is way < 500 now, and the early boot-up is fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE and Debian and distilled from this a list of functionality that makes up the early boot process and reimplemented this in C, if possible following the bahaviour of one of the existing implementations from these three distributions. This turned out to be much less effort than anticipated, and we are actually quite excited about this. Look forward to the fruits of this work in F15, when we might be able to present you a shell-less boot at least for standard desktop/laptop systems.

      Nous avons réimplémenté presque tous les scripts de démarrage et d'arrêt d'une Fedora standard en des outils C bien plus petits et plus rapides, ou dans systemd. La plupart ne seront pas activés dans F14 même si ils sont quand même inclus dans systemd. Avec cela d'activé, le système Linux complet change de visage parce que le nombre de sessions shell exécutées approche de zéro, le PID du premier terminal utilisateur est bien inférieur à 500 et les premières étapes de démarrage sont complètement parallélisées. On a regardé les scripts de démarrage de Fedora, OpenSUSE et Debian et distillé les fonctionnalités qui représentent les premières étapes de démarrage pour les réimplémenter en C, si possible avec une seule réimplémentation pour chacune de ces trois distributions. Finalement, ça a demandé beaucoup moins d'effort qu'attendu et on est pas mal excité par tout ça. Anticipez le fruit de ce travail dans F15, lorsque nous pourrons alors vous présenter un boot sans aucun script shell, au moins pour une installation standard.

      Je trouve cela très encourageant. Et pour ceux qui arguent que ce sera difficile à personnaliser, je vais vous demander si vous modifiez souvent le code qui monte les filesystem /sys et /proc, et qui fait un fsck du disque ?

      Et si c'est le cas, sans doute devriez-vous remonter vos demandes de fonctionnalités upstream.
      • [^] # Re: Systemd

        Posté par  . Évalué à 2.

        SystemD est vraiment très intéressant. Pour ce qui est de la personnalisation, il sera surement possible d'avoir des outils de config.
      • [^] # Re: Systemd

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

        >lorsque nous pourrons alors vous présenter un boot sans aucun script shell
        Excellente excuse pour se mettre un peu au C.
      • [^] # Re: Systemd

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

        On pourrait toujours avoir les scripts shells "historiques" de SysV dans un dossier, mais pas utilisés. Pour celui qui veut bidouiller quelque chose, il copie le script concerné dans le init.d de systemd, et systemd le prend en compte plutôt que sa version native en C. Ça permettrait de faire de l'override juste pour les services qu'on veut personnaliser. Par contre, ça implique aussi qu'il faut maintenir deux trucs (la version C, et la version shell, mais de toute façon plein de distros auront besoin de la version shell).
    • [^] # Re: Systemd

      Posté par  . Évalué à 1.

      11.
      > systemd supports several kinds of dependencies between
      > units. After/Before can be used to fix the ordering how units are
      > activated. It is completely orthogonal to Requires and Wants, which
      > express a positive requirement dependency, either mandatory, or
      > optional. Then, there is Conflicts which expresses a negative
      > requirement dependency. Finally, there are three further, less used
      > dependency types.

      12.
      > systemd has a minimal transaction system. Meaning: if a unit is
      > requested to start up or shut down we will add it and all its
      > dependencies to a temporary transaction. Then, we will verify if the
      > transaction is consistent (i.e. whether the ordering via After/Before
      > of all units is cycle-free). If it is not, systemd will try to fix it
      > up, and removes non-essential jobs from the transaction that might
      > remove the loop. Also, systemd tries to suppress non-essential jobs in
      > the transaction that would stop a running service. Non-essential jobs
      > are those which the original request did not directly include but
      > which where pulled in by Wants type of dependencies. Finally we check
      > whether the jobs of the transaction contradict jobs that have already
      > been queued, and optionally the transaction is aborted then. If all
      > worked out and the transaction is consistent and minimized in its
      > impact it is merged with all already outstanding jobs and added to the
      > run queue. Effectively this means that before executing a requested
      > operation, we will verify that it makes sense, fixing it if possible,
      > and only failing if it really cannot work.


      Ça va faire un sujet de recherche de plus pour les gens de MANCOOSI.
  • # Langage D

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

    Le lien pour le langage D renvoie vers la page d'homonymies.
    Le lien direct est : http://fr.wikipedia.org/wiki/D_%28langage%29
    • [^] # Re: Langage D

      Posté par  . Évalué à 2.

      J'aime bien ce langage, c'est dommage qu'il ne perce pas plus pour l'instant.
    • [^] # Re: Langage D

      Posté par  . Évalué à 3.

      Un lien interessant sur D2:
      http://www.informit.com/articles/printerfriendly.aspx?p=1609144

      C'est le chapitre sur le parallelisme (en Anglais) du livre d'Andrei Alexandrescu sur D.

      D2 n'est pas Clojure ou Erlang, mais un language dont les variables globales sont locale au thread par défaut et qui fournit des primitives d'envoi de message, de compare-and-swap2, c'est déjà très bien!
  • # Téléchargement de la version alpha

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

    Elle peut être également téléchargée via l'utilitaire préupgrade
  • # ça doit être la maturité de la distribution...

    Posté par  . Évalué à 3.

    et l'année de linux sur le desktop mais c'est la première fois, en tant qu'utilisateur basique (web, vidéo, musique, photos,...) il n'y a rien, contrairement à d'habitude, dans une prochaine version de ma distribution que je n'attende avec impatience.

    Est-ce normal docteur?
    • [^] # Re: ça doit être la maturité de la distribution...

      Posté par  . Évalué à 0.

      C'est pas exactement dans "ta distribution", mais moi j'attends avec impatience la nouvelle dépêche Linux de patrick_g !
    • [^] # Re: ça doit être la maturité de la distribution...

      Posté par  . Évalué à 6.

      Formulé comme tu l'as fait, ça veut dire que tu attends tout avec impatience. Pourtant j'ai l'impression que tu voulais dire le contraire...
    • [^] # Re: ça doit être la maturité de la distribution...

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

      Si tu regardes les nouveautés du côté de chez Ubuntu, tu vas sentir quelque chose dans la prochaine de Fedora que tu vas attendre avec impatience !

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: ça doit être la maturité de la distribution...

      Posté par  . Évalué à 2.

      Perso j'attends avec impatience le noyau 3.6.34 (bon on a droit au .35, c'est encore mieux) pour pouvoir tester mes deux touchscreens.


      J'avais justement écrit un pilote pour le quanta et alors qu'il était à peu près fonctionnel, j'ai recherché une info dans les sources du noyau et j'ai remarqué qu'un driver similaire venait d'être inclus pour mon touchscreen. Du coup depuis, j'attends la nouvelle version.

      Je vais passer à la version alpha pour faire des retours sur les nouveautés dès que possible, mais avec ma connexion internet merdique (40-60 Ko/s) le passage à la alpha via preupgrade va prendre du temps ;)


      Sinon c'est vrai que pour cette version, les nouveautés ont plus l'air d'être "sous le capot", et en tant qu'utilisateur de base il n'y aura pas grand-chose à se mettre sous la dent, (hormis peut-être le boot plus rapide, mais je trouve que Fedora 13 s'en sort déjà bien dans ce domaine)
      • [^] # Re: ça doit être la maturité de la distribution...

        Posté par  . Évalué à 5.

        > Perso j'attends avec impatience le noyau 3.6.34

        Attends un tout petit peu, il y en a juste pour une petite trentaine d'années...
      • [^] # Re: ça doit être la maturité de la distribution...

        Posté par  . Évalué à 2.

        Sur koji le noyau 2.6.34 est disponible depuis la RC1, pas besoin d'attendre patiemment qu'il arrive en stable sur F13 (même si c'est plus qu'une question de jours je pense).

        Sinon j'espère qu'il sera facile de tester la bêta de GNOME 3.0.
        • [^] # Re: ça doit être la maturité de la distribution...

          Posté par  . Évalué à 2.

          GNOME3 a été reporté à début 2011 (raison pour laquelle il ne figure plus dans la liste des fonctionnalités), ce sera donc GNOME 2.32 + les bouts de la plateforme GNOME3 en cours de finalisation
        • [^] # Re: ça doit être la maturité de la distribution...

          Posté par  . Évalué à 3.

          J'ai utilisé le noyau 2.6.34 sur koji pour tester le support de la dalle tactile justement (vu que le driver que j'avais écrit fonctionnait chez moi, autant tester pour ne pas perdre de fonctionnalités ^^), mais je ne pouvais pas le conserver à ce moment-là.

          En fait, j'ai besoin des pilotes nvidia, parce que le PC dispose d'un chipset Ion encore non géré par nouveau (mais il me semble que ça avance, faudra que je reteste avec les version plus récentes, justement).


          Malheureusement, je ne peux pas me contenter du driver vesa en attendant, parce que je veux regarder des vidéos dessus (c'est un Airis Nyos que j'utilise comme serveur multimedia)
  • # MeeGo ?

    Posté par  . Évalué à 2.

    « L'architecture de MeeGo 1.0 sur Fedora »

    J'ai pas compris ce que ça voulais dire ? Ils intègrent l'interface (à la moblin) ? Où des optimisations ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: MeeGo ?

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

      Pour moi c'est une mauvaise traduction.
      En fait c'est juste l'interface de MeeGo et les optimisations pour les netbooks qu'il possède qui ont été mises à disposition. Pour moi la notion d'architecture MeeGo n'a pas vraiment de sens…
  • # Typos et compléments

    Posté par  . Évalué à 2.

    s/libjeg-turbo/libjpeg-turbo/

    libjpeg-turbo (définition depuis wikipedia en anglais): une extension de libjpeg compatible ABI et API qui utilise les instructions SIMD x86 pour obtenir des améliorations de performances significatives sur l'implémentation de référence.

    IPMI (Intelligent Platform Management Interface): http://fr.wikipedia.org/wiki/IPMI
  • # Utilisable ?

    Posté par  . Évalué à 5.

    Je sais qu'on va me dire que c'est à mes risques et péril, que c'est pas stable et que c'est fait pour tester. Mais est ce utilisable dans la vie de tout les jours ? Je m'apprête à installer meego sur un netbook, mais si une distribution comme Fedora permet d'avoir l'interface Moblin/Meego, ainsi que leurs optimisations et le dernier noyau 2.6.35 (qui contient 2 belles avancées pour les atom), je préfèrerais encore la choisir.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Utilisable ?

      Posté par  . Évalué à 2.

      Disons qu'il y a des paquets qui ne sont pas installables pour cause de dépendances foireuses, que certains logiciels n'arrivent pas à se lancer, et que c'est plutôt fait pour être testé qu'utilisé en production.

      Mais ce qui est bien c'est que la situation ne fait que s'améliorer, et en rapportant les bugs ça contribue à avoir une F14 la plus stable possible.
      • [^] # Re: Utilisable ?

        Posté par  . Évalué à 3.

        C'est aussi ce qu'on dit pour Sid pas pour autant qu'elle n'est pas utilisable. Ces problèmes concernent quasiment toute la distrib' ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Utilisable ?

          Posté par  . Évalué à 2.

          Sid est perpétuellement expérimentale. L'équivalent de Sid chez Fedora est Rawhide.
          F14 est en alpha, puis passera en beta, rc, pour être la finale de F14. F14 ne va que se fiabiliser, ce n'est pas le cas de Sid (ni de Rawhide).
          La F15 est déjà en cours de développement.
          • [^] # Re: Utilisable ?

            Posté par  . Évalué à 1.

            F15 ? il vont finir par passer le mur du son.

            Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: Utilisable ?

          Posté par  . Évalué à 1.

          L'alpha a été retardée d'une semaine à cause de certains critères qui manquaient :
          https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Crite(...)

          Tu peux regarder les bugs les plus courants de F14 :
          http://fedoraproject.org/wiki/Common_F14_bugs

          Mais le plus simple est de l'essayer, et si c'est vraiment trop buggé, peut-être attendre la bêta fin septembre (si tout va bien).
  • # Warning : jeu de mot foireux spotted

    Posté par  . Évalué à 7.

    SystemD : encore un bricolage pour remplacer SysVinit.

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

  • # btrfs

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

    Toujours pas de btrfs proposé par défaut ? J'avais entendu dire que c'était prévu.
    • [^] # Re: btrfs

      Posté par  . Évalué à 2.

      C'est sur Ubuntu que c'est prévu pour que peu que le travail au niveau du noyau soit suffisamment avancé.
    • [^] # Re: btrfs

      Posté par  . Évalué à 3.

      Beaucoup de critiques ont été formulées dernièrement à l'encontre de brtfs dont certaines assez sévères (genre "defective by design"), je epnse que cela à contribuer à ne pas le mettre en avant plus que ça.

      Pour la source, voir lwn.net, mais j'ai un peu la flemme de chercher maintenant puisque que je suis sur mon ordiphone.
      • [^] # Re: btrfs

        Posté par  . Évalué à 5.

        Pour la source, voir lwn.net, mais j'ai un peu la flemme de chercher maintenant puisque que je suis sur mon ordiphone.

        https://lwn.net/Articles/393144/

        En même temps, il est intéressant de regarder un peu plus que le titre (qui d'ailleurs termine par un beau point d'interrogation) pour se faire un avis. La conclusion ne va d'ailleurs pas dans le même sens : "But, chances are, this is not a case of a filesystem needing a fundamental redesign. But, chances are, this is not a case of a filesystem needing a fundamental redesign. Instead, all it needs is more extensive testing, some performance tuning, and, inevitably, some bug fixes."

        Étienne
  • # Pour les utilisateurs de (La)Tex

    Posté par  . Évalué à 4.

    Faut pas être si négatif concernant le manque de nouveautés côté utilisateur lambda. Avec un peu de chance et beaucoup de sueur de Jindrich Novy, on pourra bientôt bénéficier de TexLive 2010 sous Fedora 14.

    cf: https://bugzilla.redhat.com/show_bug.cgi?id=488651#c161

    Ça nous changera de l'actuel TexLive 2006. (:ironie:)
    • [^] # Re: Pour les utilisateurs de (La)Tex

      Posté par  . Évalué à 2.

      Merci pour ce lien, ça me rassure de ne pas être le seul à trouver TeXLive plutôt compliqué à empaqueter.

      La Slack essaye, elle, de se débarasser de teTeX (plus simple à empaqueter mais il commence à devenir bien vieux), et j'essaye d'y apporter mon aide, mais je fais face aux mêmes problèmes; TeXLive pensant plutôt à une utilisation personnelle (avec un excellent installateur) qu'aux distributions.

      Je continue ma lecture, j'y trouverai peut-être des pistes un peu moins gruik que ma méthode actuelle ;) TeXLive 2010 a peut-être arrangé les choses.

      a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence

  • # Taille des ISO

    Posté par  . Évalué à 3.

    En allant télécharger les isos de la version alpha, j'ai remarqué qu'ils faisaient, sauf pour la version lxde, plus de 700Mo.
    Est-ce juste pour les tests ou ce sera la taille définitive ?
    Parce que je sais qu'il y a des cd-r de 800 et 900Mo maintenant, mais je me demande, quelle proportion de lecteur les prends en charge ?
    Parce que c'est un peu dommage d'utiliser un dvd pour un dépacement de 20Mo, autant dans ce cas là en profiter et en ajouter plus.

    Sinon, bonne continuation à Fedora et bravo pour leur travail.
    • [^] # Re: Taille des ISO

      Posté par  . Évalué à 3.

      D'après ce que j'ai suivi de la liste de discussion autour de XFCE-Fedora, la branche officielle sous gnome a perdu l'espoir de sortir un LiveCD qui tienne sur un disque de 700Mo (à confirmer cependant).

      Mais d'autres spins (notamment XFCE) ont comme objectif une iso < 700Mo. Effectivement, lors des phases d'alpha/beta, il peut arriver que l'ISO soit un chouillat trop volumineuse et ne tienne pas sur un CD classique.

      Le mieux dans ce cas est soit de passer par une clé USB, soit d'attendre une ou deux nuits le temps que de nouvelles images soit générées sur
      http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/
      • [^] # Re: Taille des ISO

        Posté par  . Évalué à 2.

        En effet pour F13 déjà il était déjà prévu de passer en LiveDVD. Les alpha et beta faisait plus que 700 Mo. Mais la finale tenait en fin de compte sur un CD. Peut-être que cela ne sera plus faisable avec F14...
        • [^] # Re: Taille des ISO

          Posté par  . Évalué à 1.

          C'est si compliqué que ça ? Il suffit de retirer un ou deux logiciels, et éventuellement les proposer lors de l'installation si il y a une connexion internet...

Suivre le flux des commentaires

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