RIP Fedora Legacy

• [^]Re: RIP Fedora Legacy

  Posté par nimnim () le 06/01/2007 à 20:48. (lien). Évalué à 3.

  L'activité de Fedora Legacy diminuait de version en version pour atteindre l'encéphalograme plat sur les dernières.
  
  Aujourd'hui Fedora ne fait que constater la mort clinique de Legacy, et basculer ses efforts de support long-terme sur RHEL & CentOS (qui ont déjà des versions à longue durée de vie, ce que Legacy n'arrivait plus à faire, et qui gagnent un accès à l'actuel Fedora Extras, que Legacy n'avait jamais réussi à intégrer).

Merci Fedora Legacy

• [^]Re: Merci Fedora Legacy

  Posté par pingoomax () le 06/01/2007 à 15:35. (lien). Évalué à 1.

  Il faut savoir que le projet Legacy n'est pas forcement définitivement mort.
  
  Il a été arreté à cause d'un nombre trop faible de contributeurs. Beaucoup d'entre eux se disent pres à se relancer dans l'aventure, mais il manque un leader.
  
  La naissance et le succes du projet Centos ont aussi joué dans la balance.

  • [^]Re: Merci Fedora Legacy

    Posté par TNorth () le 06/01/2007 à 16:36. (lien). Évalué à 4.

    Un tout petit peu HS, mais j'essaie:
    Dans le cas ou le projet serait définitivement abandonné, que ferez vous de vos serveurs (Web, Samba,etc) en production tournant sous RedHat 7.3-9 et autres Fedora ?
    Est-il raisonnable de prendre le risque de conserver ce genre de machine en prod, ou est-ce plutôt le moment de faire un upgrade (dangereux) vers une fedora récente ?

    • [^]Re: Merci Fedora Legacy

      Posté par FRLinux (page perso, ) le 06/01/2007 à 16:44. (lien). Évalué à 2.

      > Est-il raisonnable de prendre le risque de conserver ce genre de machine en prod, ou est-ce plutôt le moment de faire un upgrade (dangereux) vers une fedora récente ?
      
      Est-ce raisonnable de laisser un serveur non patché en production ? Non s'il est directement exposé à l'internet, Oui s'il est en interne et relativement isolé.
      
      Mon approche est de passer a une CentOS si tu migres depuis une RedHat 7.3 plutot qu'une Fedora. Ensuite, c'est personnel mais au niveau support de revendeurs de logiciels, si tu leur dit clone RHEL, ils te repondent.
      
      Steph

    • [^]Re: Merci Fedora Legacy

      Posté par nimnim () le 06/01/2007 à 21:04. (lien). Évalué à 3.

      Aujourd'hui en pratique tu vas avoir trois lignes de produit :
      
      – Fedora à courte durée de vie mais avec les dernières nouveautés ; pas de support commercial → serveurs de développement, expérimentations
      
      – CentOS : longue durée de vie, compatible avec les applications qualifiées pour RHEL → serveurs d'infrastructure non critiques où on reste sur les sentiers battus
      
      – RHEL : longue durée de vie, support commercial → serveurs critiques ou serveurs où on fait des trucs zazou. Le support payant n'est pas toujours du luxe !
      
      Fedora ne présente pas de risque si tu es prêt à mettre à jour ton système régulièrement (beaucoup moins que de prendre un CentOS/RHEL et intégrer tout seul les dernières nouveautés dessus) ; CentOS est bien si tu n'a pas besoin des dernières versions ou d'un support professionnel. Pour tout le reste une assurance RHEL ne fait pas de mal.

      • [^]Re: Merci Fedora Legacy

        Posté par IsNotGood () le 06/01/2007 à 21:37. (lien). Évalué à 2.

        Centos n'est pas seulement compatible avec RHEL, c'est un clone de RHEL !
        Les sources sont identiques, ce sont les sources de RHEL.
        C'est une recompilations des sources de RHEL et "rien" de plus.

        • [^]Re: Merci Fedora Legacy

          Posté par TNorth () le 07/01/2007 à 08:09. (lien). Évalué à 2.

          Donc du moment que le serveur est interne et pas accessible par l'extérieur (hormis ssh ptet ?), ce n'est pas primordial qu'il soit à jour ? (j'ai le cas d'un serveur samba)
          Il y a peu de chances que l'attaque vienne de l'intérieur dans mon cas (peu de machines dans le réseau interne, collaborateurs de confiance)

          • [^]Re: Merci Fedora Legacy

            Posté par IsNotGood () le 07/01/2007 à 09:07. (lien). Évalué à 2.

            Je ne crois pas que tu réponds à moi mais je vais te faire ma réponse.
            
            > Donc du moment que le serveur est interne et pas accessible par l'extérieur (hormis ssh ptet ?), ce n'est pas primordial qu'il soit à jour ? (j'ai le cas d'un serveur samba)
            
            Si le serveur rend le service qu'on demande de lui, qu'il ne peut être attaqué et s'il n'y a que des utilisateurs de confiance, il est tout à fait raison d'avoir un serveur qui n'est pas à jour.
            
            > hormis ssh ptet ?
            
            Je te conseille de le désactiver. Ou du moins de ne pas le rendre accessible depuis l'extérieur. Même si ton ssh est à jour, il peut y avoir un trou de sécurité dans ta libc qui n'est pas à jour qui permet d'attaquer le serveur via ssh par exemple. Ce n'est pas courant mais c'est possible.

CodecBuddy ?

• [^]Re: CodecBuddy ?

  Posté par IsNotGood () le 06/01/2007 à 16:26. (lien). Évalué à 5.

  http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy
  

  
  Details
  
  Basically:
  
  1. Detect that they tried to play a codec that wasn't installed
  2. For certain sets of such codecs (MP3, MPEG, etc.) explain how Freedom Isn't Free, why we can't ship such support, and how to use free formats.
  3. Point them to a site where they can get legal support for such codecs, if such support exists.

  • [^]Re: CodecBuddy ?

    Posté par Wawet76 (page perso, ) le 06/01/2007 à 16:41. (lien). Évalué à 2.

    MMmmmhhh... C'est excellent si il font ça.
    
    Ils font pareil pour les pilotes vidéos (et autre) non libres ?

    • [+] [^]Re: CodecBuddy ?

      Posté par FRLinux (page perso, ) le 06/01/2007 à 16:47. (lien). Évalué à -2.

      On parlait de codecs, pas de pilotes ...
      
      

Re:

• [^]Re: Re:

  Posté par eltatio () le 06/01/2007 à 16:50. (lien). Évalué à 2.

  Concernant le 2.6.19 dans Fedora, je ne suis pas sur que les problèmes ne dépendent que de Xen ...
  
  Cf les explications de Daves Jones , le kernel dev de fedora :
  
  => http://kernelslacker.livejournal.com/66702.html
  
  "I'm really nervous about pushing out 2.6.19 as an update for FC5/FC6 users"

  • [^]Re: Re:

    Posté par IsNotGood () le 06/01/2007 à 18:30. (lien). Évalué à 1.

    Autant pour moi.
    
    Mais c'est ce même Daves Jones qui a dit les problèmes qu'il y avait avec Xen et qu'il était envisagé de le virer de Fedora (du moins de ne pas le supporter ; c-à-d qu'il peut-être viré à tout moment).
    Désolé, je n'ai pas l'url de son commentaire.
    
    En gros il semble que Xensource attendent la sortie de RHEL 5 pour se "positionner" et bosser à nouveau en upstream.

    • [^]Re: Re:

      Posté par nimnim () le 06/01/2007 à 22:00. (lien). Évalué à 2.

      Plus exactement, XenSource est tombé dans le travers habituel des vendeurs propriétaires (ne pas suivre les évolutions du noyau, ne pas essayer très fort d'intégrer son code chez Linus, laisser Red Hat se palucher l'adaptation entre leurs évolutions et celles du noyau).
      
      Ça ne fait pas rire du tout Daves Jones (ni son employeur), dès qu'une alternative s'intégrant mieux à l'écosystème libre sera disponible XenSource va se faire lourder violemment (et il y a une fripotée d'autres projets de virtualisation arrivant à maturité aujourd'hui).
      
      Je pense que XenSource surestime fortement son levier sur Red Hat, et se prépare des lendemains douloureux.

      • [^]Re: Re:

        Posté par IsNotGood () le 06/01/2007 à 23:56. (lien). Évalué à 1.

        D'accord mais il faut aussi se mettre à la place de XenSource avant de lui jeter la pierre.
        Ce qui arrivera selon moi probablement est que Red Hat (mais aussi Novell) raffle le gateau de la virtualisation sous Linux. Plus XenSource bosse sur Linux et plus ça profite à Red Hat/Novell. Si Red Hat/Novell bossent sur Xen pour l'intégrer à Linux et le débugger, ça profite à peine à XenSource, sauf si ce qui est fait peut être utilisé pour Xen sous Windows par exemple.
        
        C'est un grain de sable, mais il ne faut pas croire que la création de XenSource a été ou est une mauvaise chose. Certe Daves Jones a eu des mots un peu dur envers XenSource. Mais il faut se mettre à sa place, c'est lui qui en a chié :-)

        • [^]Re: Re:

          Posté par nimnim () le 07/01/2007 à 14:08. (lien). Évalué à 2.

          « Plus XenSource bosse sur Linux et plus ça profite à Red Hat/Novell. Si Red Hat/Novell bossent sur Xen pour l'intégrer à Linux et le débugger, ça profite à peine à XenSource, sauf si ce qui est fait peut être utilisé pour Xen sous Windows par exemple. »
          
          Je crois que tu ne te rends pas compte que XenSource a une toute petite fenêtre d'opportunité :
          — les nouveaux processeurs x86 64bit ont des extensions de virtualisation qui rendent une grande partie du code Xen inutile
          — vmware truste déjà le marché de la virtualisation propriétaire indépendante du système. Sa solution marche bien. vmware est adossé à un gros vendeur. La seule possibilité pour Xen de faire son beurre à moyen terme est de devenir la solution de virtualisation de référence sous un OS — XenSource ne délogera pas vmware sans appui des vendeurs d'OS
          — tous les autres vendeurs de systèmes d'exploitation (Microsoft, SUN…) ont des systèmes de virtualisation propriétaires déployés ou dans les bacs. Linux est le seul OS majeur qui ne s'est pas encore positionné. Dès que Microsoft aura industrialisé sa solution de virtualisation Xen sera entre le marteau vmware et l'enclume Microsoft sous Windows. L'accord avec Novell ce n'est pas pour faire du Xen.
          
          Si XenSource peut faire rentrer son code dans le noyau de Linus Xen sera de facto la solution de virtualisation sous Linux, et il y aura des contrats de support à la clef (à la MySQL AB). Sinon Xen sera marginalisé à terme comme c'est déjà prévisible sous Windows & Solaris.
          
          Le travail d'intégration que Red Hat fait pour XenSource en ce moment est la clef de son avenir, et XenSource est suicidaire de ne pas lui donner tout son appui.

          • [^]Re: Re:

            Posté par uᴉpɹɐʌɹɐɟ (page perso, ) le 07/01/2007 à 23:18. (lien). Évalué à 2.

            Si XenSource peut faire rentrer son code dans le noyau de Linus Xen sera de facto la solution de virtualisation sous Linux

            
            
            à moins que je n'aie pas bien compris la portée de tout cela, il me semble plutôt que c'est KVM qui fera cela dès la prochaine version du noyau :
            
            http://kvm.sourceforge.net/
            
            sauf quand même que kvm nécessite des processeurs qui supportent cela (VT pour intel et SVM pour amd)

            --
            "C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard"
            ---------
            Les dalles brillantes c'est moche et nul

            • [^]Re: Re:

              Posté par nimnim () le 08/01/2007 à 09:47. (lien). Évalué à 3.

              « à moins que je n'aie pas bien compris la portée de tout cela, il me semble plutôt que c'est KVM qui fera cela dès la prochaine version du noyau :
              
              http://kvm.sourceforge.net/ »
              
              Oui l'équipe du projet KVM a fait l'effort d'intégration que Dave Jones reproche à XenSource de ne pas faire
              
              « sauf quand même que kvm nécessite des processeurs qui supportent cela (VT pour intel et SVM pour amd) »
              
              En pratique c'est tous les processeux x86 AMD & Intel récents, et comme de toute manière faire de la virtualisation demande des systèmes dimentionnés pour (au moins au niveau mémoire) l'avantage de Xen est très relatif et s'amenuise de jour en jour

• [^]Re: Re:

  Posté par patrick_g (page perso, ) le 06/01/2007 à 17:50. (lien). Évalué à 3.

  >> A propos de la virtualisation, Xen sera peut-être supprimé de Fedora, du moins il ne sera peut-être plus supporté.
  
  Bizarre car ce n'est pas la position officielle.
  A une question sur la liste de diffusion il y a eu cette réponse :
  
  > Does this mean that Xen is gone?
  
  No; there's no reason the tools can't support multiple types of
  virtualization. That's why libvirt was started in the first place

  • [^]Re: Re:

    Posté par IsNotGood () le 06/01/2007 à 19:02. (lien). Évalué à 1.

    > Bizarre car ce n'est pas la position officielle.
    
    Je n'ai pas dit que Fedora allait abandonner la virtualisation.
    
    Je n'ai toujours pas mis la main sur le mail de Daves Jones qui indiquait les problèmes de Xen mais voilà un autre mail intéressant :
    http://article.gmane.org/gmane.linux.redhat.fedora.advisory-(...)
    

    lhype may take quite a while. I'm optimistically thinking we can squeeze 2.6.21 into FC7. I expect .20 to land say, mid to end of January. given where lhype is today though, that's still not going to be a huge improvement, so at best we can hope for a 'tech preview' type thing that may be useful for people actually hacking on it.
    
    I fear we may actually have to support Xen for at least one more Fedora release.

    
    
    On sent que le support de Xen est limite à contre coeur.
    Lhype : http://lhype.ozlabs.org/

Lobbying au sujet des firmwares : bien, mais un peu tard

• [^]Re: Lobbying au sujet des firmwares : bien, mais un peu tard

  Posté par nimnim () le 07/01/2007 à 14:28. (lien). Évalué à 1.

  « C'est une excellente nouvelle.
  
  Mais je regrette un peu que les grandes distributions (ça comprend aussi Debian, qui a dû gérer de longs débats sur ce sujet récemment) n'aient pas suivis l'appel de Theo de Raadt, lorsqu'il avait initié une telle tentative et appelait les linuxiens à l'aide, il y a plus de deux ans. »
  
  Theo de Raadt :
  — demandait le microcode nécessaire à des pilotes BSD qui n'étaient pas utilisables sous Linux (pour des raisons techniques ou légales)
  — a systématiquement concentré ses attaques sur les vendeurs qui travaillaient avec Linux (même si on peut considérer que leur collaboration est incomplète, ce n'est pas exactement le bon moyen pour l'encourager)
  
  L'« appel » de Théo consistait à brûler les ponts entre les vendeurs de matériel et les acteurs Linux, histoire qu'ils soient dans le même pétrin que lui. Il proposait généreusement à Linux de se faire hara-kiri pour le bénéfice d'OpenBSD. Le manque de soutien était prévisible.
  
  « En corrélation, Jeff Garzik vient de publier un état des lieux (« Linux: Wireless State of the Union ») : http://kerneltrap.org/node/6053 »
  
  On prendra l'option généreuse et on considèrera que tu as mal regardé l'année du message.

  • [^]Re: Lobbying au sujet des firmwares : bien, mais un peu tard

    Posté par herodiade () le 07/01/2007 à 16:36. (lien). Évalué à 4.

    Plait-il ?
    
    - Il demandait les microcodes nécessaires aussi bien aux pilotes Linux qu'aux BSD (ou autres OpenSolaris). Tu sait ce dont il s'agit ? Le firmware est nécessaire pour que le chipset fonctionne, quel que soit l'OS. Mais il faut pouvoir le distribuer avec l'OS si on veut que ça marche out of the box.
    - A concentré ses attaques sur les fabriquants de chipsets wifi qui ne fournissent pas les firmwares nécessaires, sans plus de discrimination.
    
    Il s'est seulement énervé à postériori contre l'inertie (ou pire) des distros linux qui ne l'ont pas soutenus, ont signé des accords avec des constructeurs (au lieu de réclamer le droit de redistribution général), intègrent joyeusement ndiswrapper et autres saletés du genre, au mépris des idéaux du libre (et mettant, de ce fait, des batons dans les roues de ceux qui ne veulent pas de concessions bancales).
    
    Si tu appelle un « pont » ou une collaboration le fait de fournir sans les specs un driver développé en interne par Intel et qui nécessite un binaire root proprio en userland pour fonctionner, autant utiliser directement un OS totalement propriétaire, tu aura la vie plus facile. Il s'agit de savoir avec qui (et quelles pratiques) tu es solidaires : celles évoquées par TdR dans son appel, ou Intel.
    Car il s'agit bien d'un appel à la solidarité, à la coopération. Et contrairement à ce que tu semble prétendre : dans l'interet de tous.
    
    Le cas échéant, j'aimerai savoir quels « ponts » existent entre les responsables wifi chez Broadcom, TI, etc. et le kernel linux libre (j'entends : pas celui de ubuntu, mandriva, rhel ou suse).
    
    Et : « histoire qu'ils soient dans le même pétrin que lui. ». Ils le sont, de fait. Et c'est bien pour ça que ça a fumé sur les m-l debian, et que Fedora entreprend de réagir. Seulement, ils faisaient hypocritement la sourde oreille à l'époque parce qu'ils avaient des solutions merdiques (comme ndiswrapper, ou la distribution illégale de firmwares dans le kernel, ou encore la distribution par les distros commerciales sous accords commerciaux).
    
    Oui pour la date du topo de Garzik, visiblement je n'ai pas encore intégré le 0x7D6 + 1 (j'étais quand même surpris que les choses semblent si peu évoluer).

    • [^]Re: Lobbying au sujet des firmwares : bien, mais un peu tard

      Posté par nimnim () le 08/01/2007 à 09:44. (lien). Évalué à 3.

      « Si tu appelle un « pont » ou une collaboration le fait de fournir sans les specs un driver développé en interne par Intel et qui nécessite un binaire root proprio en userland pour fonctionner, autant utiliser directement un OS totalement propriétaire, tu aura la vie plus facile. Il s'agit de savoir avec qui (et quelles pratiques) tu es solidaires : celles évoquées par TdR dans son appel, ou Intel. »
      
      Je suis solidaire des développeurs Intel qui postent leur code sur les listes linux, écoutent les retours, font du lobbying en interne pour supprimer le binaire en question (et aux dernières nouvelles ils y sont arrivés pour les générations suivantes) et n'ont pas besoin d'être humiliés publiquement dans la presse auprès de leur hierarchie.

      • [^]Re: Lobbying au sujet des firmwares : bien, mais un peu tard

        Posté par nimnim () le 08/01/2007 à 09:54. (lien). Évalué à 1.

        Pour prendre un autre exemple Théo a eu la brillante idée d'attaquer OLPC alors qu'un pilote libre était déjà prévu et publiquement annoncé. La meilleure façon de se retrouver dans sa ligne de mire semble de travailler sur un pilote libre avec des développeurs Linux.