- un coeur (core) supporté directement par des employés Red Hat avec l'aide de la communauté,
- et extras sous la responsabilité de la communauté entièrement.
28 décisions pour la septième version de la distribution (dont la sortie est prévue le 26 avril 2007) viennent de parvenir sur la liste de diffusion, dont la plus importante est de supprimer entièrement cette distinction et de proposer un seul ensemble de programmes supportés équitablement entre Red Hat et sa communauté. Un seul dépôt de logiciel existera dont les outils de compilation seront dans la communauté et open-source, et qui créera les ensembles de CD que celle-ci souhaite.
Cette décision vient après une nouvelle moins réjouissante : la fin du projet Fedora Legacy dont le but était de proposer un support par la communauté sur du long terme.
Les nouveautés annoncées
- Modification du système de compilation pour gérer la fusion Core et Extras
- Fusion de Core et Extras dans le gestionnaire de source
- Utilisation du nouvel outil pungi pour générer des jeux de CDs suivant la demande de la communauté
- Un jeu de CD Fedora Desktop
- Un jeu de CD Fedora Server
- Un jeu de CD Fedora KDE. Cela vient notamment après le projet UnleashKDE dont l'objectif était de pousser Fedora à laisser à la communauté le support de KDE afin d'obtenir une version qui ne pouvait être que mieux.
- Génération de live-CDs
- Possibilité de personnaliser des paramètres de distribution qui ne concernent pas le packaging (??)
- Utilisation des drivers libata pour le support PATA (parallel ATA) à la place de la couche IDE
- Amélioration des performances des phases de démarrage et d'arrêt
- Amélioration de la gestion des réseaux sans-fil
- Ajout de tous les firmwares disponibles pour le sans-fil. Cela passe par une phase de militantisme auprès des différents fournisseurs pour obtenir une libération de ceux-ci.
- CodecBuddy, outil de gestion des codecs non-fournis par défaut dans la distribution, généralement pour des questions d'ordre légal
- Arrêter la prolifération du nombre de dictionnaire et modifier les différentes applications (OpenOffice, Thunderbird, aspell, etc...)
- Support des systèmes de fichiers chiffrés
- Changement rapide d'utilisateur sur le desktop
- Débuggage de la couche Firewire
- Modification du noyau par défaut pour économiser de l'énergie et ainsi améliorer l'autonomie des portables (tickless kernel)
- Correction des réveils réguliers de matériels gérés par la distribution dans la même optique
- Ajout du support pour la virtualisation avec KVM
- étude de nouveaux systèmes de démarrage (init-ng, upstart), sans forcément les implémenter.
- Utilisation des drivers Nouveau pour les cartes NVidia. Fedora deviendrait la première distribution à le faire, alors que l'étape de développement est encore loin d'une stabilité parfaite, montrant encore une fois l'engagement de Red Hat pour des solutions libres, qui profiteront un jour à l'ensemble de la communauté.
- Amélioration de la vitesse de Yum et RPM, gros point faible actuel
- Ajout du support pour RandR 1.2 (configuration automatique de l'affichage, hotplug d'écran, etc...)
- Migration de l'outil de gestion des logs systèmes vers syslog-ng
- Faire de l'outil de mise à jour de Fedora un outil utilisable par tous
Aller plus loin
- 28 améliorations pour Fedora 7 (4 clics)
- Fin de Fedora Legacy (3 clics)
- Fedora.redhat.com (1 clic)
- Nouvelles fonctionnalités de la version 7 (2 clics)
- Fedoraproject.org (2 clics)
# RIP Fedora Legacy
Posté par FRLinux (site web personnel) . Évalué à 4.
[^] # Re: RIP Fedora Legacy
Posté par nimnim . Évalué à 3.
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
Posté par mcjyc (site web personnel) . Évalué à 2.
Chapeau bas !
c'etait un travail de titan, encore bravo !
le projet s'arrete, mais je crois qu'il a plus qu'atteint son but.
un grand merci à la communauté d'avoir repris le support apres que le support officiel soit arrivé à sa fin.
[^] # Re: Merci Fedora Legacy
Posté par pingoomax . Évalué à 1.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 3.
– 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 . Évalué à 2.
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 . Évalué à 2.
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 . É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)
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 ?
Posté par Jean Roc Morreale . Évalué à 2.
ça serait excellent d'avoir un programme qui se dépatouillerait pour trouver les codecs nécessaires à la lecture d'une vidéo, enfin si c'est bien ce dont il s'agit.
[^] # Re: CodecBuddy ?
Posté par IsNotGood . Évalué à 5.
[^] # Re: CodecBuddy ?
Posté par Wawet76 . Évalué à 2.
Ils font pareil pour les pilotes vidéos (et autre) non libres ?
[^] # Re: CodecBuddy ?
Posté par FRLinux (site web personnel) . Évalué à -2.
# Re:
Posté par IsNotGood . Évalué à 8.
On voit qu'une des raisons est de proposer plusieurs saveurs de distribution (Gnome, Kde, client, serveur, etc). Mais il n'était pas indispensable de fusionner Core et Extra pour ça.
La plus grande raison est de répondre à la demande de la communauté. Il va de soit que Red Hat y vois aussi un intérêt. Permettre à la communauté de participer plus à Fedora Core. Pour FC7 on ne sera plus avec une communauté qui propose des patchs, discute d'évolution pour Fedora Core. Des membre de la commauté pourront être totalement responsable d'un paquet par exemple. Autre point important, la distinction employé Red Hat et membre de la communauté s'atténue. C'est une très bonne nouvelle, bien que c'était prévu depuis longtemps, mais Red Hat a "trainé".
> Cela vient notamment après le projet UnleashKDE dont l'objectif était de pousser Fedora à laisser à la communauté le support de KDE afin d'obtenir une version qui ne pouvait être que mieux.
Il ne sagit de laisser à la communauté le support de KDE. Red Hat ne se désengage pas de KDE. Il y aura toujours autant de développeur de Red Hat sur KDE (et reconnaissons le, ils sont peu).
Il y avait une demande significative de la par de la communauté KDE pour bien supporter KDE dans Fedora. Avec KDE dans Fedora Core se n'était pas possible ou difficile. D'où l'idée de déplacer KDE dans extras.
Notons qu'il y a beaucoup de paquet dans Fedora Extras qui sont important pour Red Hat et maintenu par Red Hat. Fedora extras n'est pas exclusivement réservé à la communauté.
M'enfin, avec la fusion de Fedora Core et Fedora Extras c'est maintenant sans object.
> Génération de live-CDs
Au fait, il y a FC6 en live-CD réalisé officiellement par Fedora (c'est la première fois) :
http://lwn.net/Articles/215388/
> Ajout de tous les firmwares disponibles pour le sans-fil. Cela passe par une phase de militantisme auprès des différents fournisseurs pour obtenir une libération de ceux-ci.
"libération" est un peu fort. Ce que demande Fedora maintenant est que les firmware puissent être librement distribué. Il ne sagit pas d'avoir les sources sous GPL pas exemple.
Ceci respecte la "charte" de Fedora. Les firmwares ne tournent pas sous Fedora, ils y transitent seulement. Tout ce qui tourne sous Fedora doit être libre. Free software et exceptionnellement seulement opensource. L'objectif est d'être 100 % Free software. C'est fait pour Fedora Core, ce n'est pas encore fait pour les paquets dans Fedora Extras (reporté à FC7^WF7 peut-être F8).
> Ajout du support pour la virtualisation avec KVM
A propos de la virtualisation, Xen sera peut-être supprimé de Fedora, du moins il ne sera peut-être plus supporté.
Fedora n'est pas satisfait par Xensource et l'intégration de Xen dans Fedora a été une tâche ardue et son support encore plus. Par exemple Xensource supporte que Linux 2.6.16. Red Hat a fait le portage vers Linux 2.6.18 mais est trop occupé pour faire le portage vers 2.6.19 ou 2.6.20 (RHEL 5 est en cours de développement, et d'ailleur commence à avoir un retard signification).
En conséquence il n'y a pas de Linux 2.6.19 dans les mises à jours de FC6 par exemple. Or l'objectif de Fedora est d'être au plus proche des développements upstream.
Il ne sagit pas de jeter la pierre à Xensource et soyons plus que reconnaissant de leur fabuleux travail.
> étude de nouveaux systèmes de démarrage (init-ng, upstart), sans forcément les implémenter.
Ça fait depuis longtemps que c'est dans les cartons :-)
Il me semble qu'il y a un manque de motiviation.
NB : Ces objectifs sont ceux actuels ! Ils ne seront peut-être pas réalisés et d'autres non listés seront peut-être fait. C'est uniquement a partir de la beta "test 2" qu'on sait ce qu'il y aura dans la version finale.
> Cette décision vient après une nouvelle moins réjouissante : la fin du projet Fedora Legacy dont le but était de proposer un support par la communauté sur du long terme.
Le support de Fedora par Fedora passe de 8/9 mois à 13/14 mois. Ça va compenser. Autre avantage, il faudra mettre à jour sa distribution toutes les deux distributions et non à chaque sortie de distribution si on veut un système supporté.
Il y a aussi l'objectif de faire Entreprise Extras. Des paquets pour RHEL. Evidemment ça sera utilisable par Centos par exemple et les utilisateurs de Centos et autres clones de RHEL sont chaudement invités à participer. De plus il a été constaté que beaucoup de contributeur à Fedora utilise Fedora mais aussi RHEL et/ou un clone de RHEL.
Ces paquets ne seront pas supportés par Red Hat (même si des employés de Red Hat y participent). Ils seront livrés telquel.
Avec la fusion de Fedora Core avec Fedora Extras se projet va probablement prendre du retard (initialement pour RHEL 5).
http://fedoraproject.org/wiki/EnterpriseExtras
[^] # Re: Re:
Posté par eltatio . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 2.
Ç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 . Évalué à 1.
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 . Évalué à 2.
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 B16F4RV4RD1N . Évalué à 2.
à 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)
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: Re:
Posté par nimnim . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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-(...)
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
Posté par herodiade . Évalué à 2.
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.
Un appel massif et groupé aurait tout de même été bienvenu, et les fabricants de chipsets wifi ne se seraient peut-être pas permis, à cette époque, de rétorquer à TdR « mais non, il n'y a pas de problème avec nos licences, la preuve : aucun représentant d'une distro majeure ne s'est plaint, et Mandriva et SuSE ont accepté de signer des accords » ...
http://kerneltrap.org/node/4818
http://marc.theaimsgroup.com/?l=openbsd-misc&m=111108503(...)
http://kerneltrap.org/node/4115
Faudra-t-il attendre encore un an pour que les distros importantes réclament officiellement les specs et des outils de management libres aux fabriquants de chipsets RAID (Adaptec en tête) ?
Pour ne pas rater l'occasion de leur faire de la contre-publicité : les plus mauvais coucheurs parmi les fabriquants de chipsets wifi, ceux qui ne veulent rien entendre, ne facilite pas le support des OS libres (en ne donnant pas les specs et/ou le droit de redistribuer les firmwares) sont principalement :
- Broadcom (les pires, ils arrivent même à poser des problèmes avec leurs chipsets ethernet comme le - très mauvais - tg3).
- TI (Texas Instruments), par ex. http://kerneltrap.org/node/4115
- Connexant
- Intel (de pire en pire, leur chipset 3945 necessite un daemon binaire root et proprio sous linux), par ex. http://kerneltrap.org/node/7184 ou http://kerneltrap.org/node/4202
En corrélation, Jeff Garzik vient de publier un état des lieux (« Linux: Wireless State of the Union ») : http://kerneltrap.org/node/6053
[^] # Re: Lobbying au sujet des firmwares : bien, mais un peu tard
Posté par nimnim . Évalué à 1.
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 . Évalué à 4.
- 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 . Évalué à 3.
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 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.