Aucun.

Le problème est de le faire plus pour Mandriva que pour d'autres. Notes comme les sites américains qui n'affichent pas de préférence pour une distribution traitent toute les distributions à égalité. Par exemple, il n'y a pas de favoritisme envers Red Hat/Fedora (pourtant c'est une distribution américaine) et toute les news Mandriva sont passées sans que personne proteste :
http://www.osnews.com/comment.php?news_id=15840

Les news Mandriva :
http://www.osnews.com/topic.php?icon=39
Les news Fedora :
http://www.osnews.com/topic.php?icon=61

Si la ligne éditoriale de linuxfr est de privilégier les distributions françaises, OK, très bien, pas de problème, fabuleux, mais ça doit être dit dans la ligne éditoriale. Or ce n'est pas ce qui y est dit.

Un site pro-debian :
http://www.debianplanet.org/

Aucun problème pour moi, c'est clairement annoncé. (OK, l'exemple n'est pas terrible).

Si tu viens sur linuxfr et qu'on ne te dis pas que linuxfr a un faible pour Mandriva, tu vas croire que Mandriva est le centre du monde. Tu vas être trompé.
Qu'il y ait moins de news sur Fedora que sur Mandriva n'est pas un problème si à l'origine il y a moins de proposition de news (hors doublon). Linuxfr ne donne que les news qu'on lui propose et ce point est claire. Qu'il y ait moins de news sur Fedora que sur Mandriva car les modérateurs privilégient Mandriva, ce n'est pas normal car il est nul par indiqué que linuxfr privilégie Mandriva.

[ Répondre ]

> En tout cas, je pense que c'est plus probable que ce soit pour cette raison que pour les PDA.

Ta remarque est pertinante, mais je ne crois pas que le travail fait sur Fedora Core pour la "modulariser" ait comme priorité OLPC. OLPC est un "fork" de Fedora Core. Le travail sur Fedora Core portera ses fruits à long terme (et peut-être pas pour OLPC (ou alors pour OLPC 2 "le retour" :-)).

Tu peux en juger par toi même :
http://olpc.download.redhat.com/olpc/streams/development/lat(...)

C'est un OS assez spécifique (je ne parle pas du noyau, mais de l'ensemble).

> Red Hat prétends ne pas croire en "linux sur le desktop"

Red Hat n'a pas dit ça. Je ne comprend pas comment font les gens pour si peu savoir lire. Il ne faut pas seulement se sourcer sur "troll magazine". Red Hat a dit qu'il leur semblait qu'il n'y avait pas ACTUELLEMENT assez de demande autour du desktop linux pour y faire du "buziness".
ACTUELLEMENT, Red Hat estime qu'il y a un buziness pour les stations de travail (ils ont une offre).
ACTUELLEMENT, Red Hat estime qu'il y a un buziness (léger) pour le desktop en entreprise (ils ont une offre).

De plus Red Hat a dit ça il y a de "nombreuses" années.
Et peut-on leur donner tord ?
Ben non. Les distributions orientés desktop en chient. Voir Mandriva qui cible aussi les professionnels pour faire de la tune. Voir Ubuntu qui marche fort mais n'a aucun buziness (sauf pour l'avenir et ça cible les professionnels).

Si Red Hat ne croyait pas au desktop linux (à long terme), tu crois qu'ils seraient, sont, et seront probablement encore le plus gros contributeur à Gnome ?

Ton troll n'a pas de sens.

> et je ne pense pas que "linux sur pda" ai vraiment plus de chance de percer.

C'est du long terme. Comprendre que ce n'est pas en mois qu'on va y voir plus claire mais en années. Notes que OLPC c'est "chaud". Ce n'est pas du long terme et donc j'ai du mal à l'associé aux efforts actuels de Fedora Core.

[ Répondre ]

En voyant le bandeau de tux-planet, ça m'a fait penser au boulot que fait Diana Fong et que j'apprécie beaucoup beaucoup.

L'image (visuelle) des CD (pour ceux qui font des CD :-)) :
http://fedoraproject.org/wiki/Artwork/CDArtFC6

DNA :
http://82.99.245.51/more/

Le thème DNA sur FC6:
http://people.redhat.com/dfong/fc6graphics/

Diana Fong sur people.redhat.com :
http://people.redhat.com/dfong/
Fouillez, c'est du bonheur pour les yeux.

Pensez Fedora :
http://people.redhat.com/dfong/icFedora/060531/fXray1.jpg

Buvez Fedora :
http://people.redhat.com/dfong/icFedora/060816/tea1.jpg

Jouez Fedora :
http://people.redhat.com/dfong/icFedora/060607/FourA1.jpg

Battissez Fedora :
http://people.redhat.com/dfong/icFedora/060705/legoA1.jpg

[ Répondre ]

> Tout ça pour dire que quand je vois des clients qui imposent une distribution FedoraCore sur un serveur de prod, tout ça pour économiser les quelques 300$ de souscription annuelle auprès de RedHat ça me hérisse le poil.

Moi pas vraiment.
Si une RHEL n'est pas intéressante par rapport à une Fedora, alors autant prendre Fedora.
Mais Fedora, bien que gratuite, peut aussi avoir un coût et notamment pour un serveur de prod. Fedora n'a pas de garanti de compatibilité source/binaire, a un support court et n'a pas de support des éditeurs logiciels et fabricants de hardware.
Mettre un serveur Fedora de prod à jour tout les ans peut être plus couteux que de prendre qu'une souscription RHEL et être tranquille pendant 7 ans. Par exemple avec Fedora si c'est un verseur web, les scripts php ne vont peut-être pas apprécier le passage à php6, etc. Avec RHEL il y a un coût en monnaie mais pas de coût en expert (pour passer les scripts php de php5 à php6 par exemple). Il le second est plus élevé que le premier, il faut prendre une RHEL. C'est là tout l'intérêt de RHEL et sa *vraie* plus-value. Sinon autant rester sous Fedora.

Ce qui me "hérisse le poil" c'est ceux qui prennent une Centos/etc. Centos c'est une RHEL sans que Centos en supporte les coûts (developpement, backport des patchs (pour la garantie sources/binaire), tests, etc).
Ce truc là m'énerve BEAUCOUP !

Je le "tolère" pour ceux qui n'ont pas d'argent. Mais pour les entreprises je le "tolère" beaucoup moins.

[ Répondre ]

Pour la première fois, Red Hat a fait des efforts significatifs pour une distribution plus "maigre" sur le disque dur pour ceux qui le désire et s'en donne la peine. Ainsi, même s'il y avait quelques raisons légitime à ça, l'installation d'evince ne demande plus l'installation de nautilus (il y en a qui n'utilise pas nautilus même s'il apprécie Gnome ; j'en fais parti). Personnellement, que nautilus soit installé ou non, je m'en fous. Mais que je sois obligé de le faire tourner alors que je ne l'utilise pas m'énerve beaucoup (heureusement, ce n'est pas le cas).

Des améliorations ont été faites à plein d'endroit. Ceci n'impacte pas l'utilisateur "moyen". Ceci n'impacte pas l'installation "classique" d'une Fedora via anaconda.

Alors pourquoi ? Pas pour bouffer du temps pour quelques geek qui veulent récupérer quelques Mo sur leur disque dur. Ca ne fait pas du tout parti dans priorité de Red Hat.

Ceci est fait dans une vision à long terme. Red Hat estime qu'il va y avoir un rapprochement encore plus marqué entre les ordinateurs personnels et les PDA. Les PDA auront toujours moins de puissance, moins de place disque, etc que les PC mais a moyens ils pourront faire tourner une distribution "classique" pour peut qu'elle soit modulaire.

Ainsi, il y aura peut-être une Fedora 12 pour PDA réalisé en ne faisant que quelques retouches de la Fedora 12 "de base".

C'est peut-être que du délire, l'histoire jugera.

[ Répondre ]

> Désolé pour la femme de ménage.

Hé l'aristo, tu pourrais nettoyer tes cochonneries toi même.

[ Répondre ]

> Pour rappel la distribution Fedora est une version alpha ou beta de la distribution RedHat.

Oui et non.

La FC6, n'est pas la version alpha/beta de la prochaine RHEL 5 (qui d'ailleur est actuellement en phase de test alors que FC6 n'est pas sorti).

Voila l'idée de Red Hat (interprétation personnelle). Si Red Hat veut ajouter SeLinux à RHEL (distribution non communautaire), il le font en premier dans Fedora (distribution communautaire). Red Hat profite de la communauté, la communauté profite des développements de Red Hat, profite de cette "porte ouverte" pour influencer les développements et profite d'avoir une distribution gratuite. C'est du gagnant-gagnant. Notons aussi que Red Hat n'a aucun intérêt dans Fedora si Fedora ne lui permet pas d'améliorer RHEL. Red Hat ne vend pas Fedora (0 $) et ne vend pas de support pour Fedora (0 $). Néanmoins Fedora coute chère. A titre d'exemple, c'est plus d'un million de $ par an rien que pour la bande passante !

Une autre façon de voir la "chose". Fedora est la branche principale de la distribution Red Hat. Donc ils y implémentent de nouvelles idées (donc du code alpha/beta). RHEL est un fork de cette branche (c-à-d Fedora). RHEL 4 était un fork de FC3, RHEL 5 est un fork de FC6 (de FC6 test2 précisément).

Dans "Fedora est une version alpha de RHEL", il ne faut pas prendre "alpha" dans le sens "logiciel non aboutis" mais dans le sens "lieu où de nouvelles idées sont en gestation, lieu où elles sont réalisées".
Ainsi RHEL n'est plus un lieu d'innovation. D'ailleurs la prochaine RHEL 5 n'a rien de plus en terme d'innovation que la prochaine FC6. Pour les versions précédentes de RHEL, ce n'était pas le cas. Par exemple RHEL avait GFS mais pas Fedora, etc. Je préfère indéniablement la nouvelle situation.
Que Fedora soit devenu indiscutablement la branche principalement de Red Hat est une bonne nouvelle.

[ Répondre ]

> Il n'y a pas de live CD pour les versions de test.

J'ai dit une bêtise :-)
Il y a un live cd pour FC6 test 2 :
http://www.redhat.com/archives/fedora-announce-list/2006-Aug(...)

Pour FC6 test 3, je ne sais pas si c'est plannifié.

[ Répondre ]

L'annonce de FC6 test 3 :
http://www.redhat.com/archives/fedora-test-list/2006-Septemb(...)

Fedora-france (Site d'entraide orienté forum) :
http://www.fedora-france.org/

[ Répondre ]

Ooops, il y a DNA. Mais il ne se voit pas lorsque le bureau est déjà en place.

[ Répondre ]

Il n'y a pas un nouveau theme complet.
Il y a de nouvelles icones qui remplace celles de bluecurve.
http://fedoraproject.org/wiki/Artwork/EchoDevelopment

[ Répondre ]

Il n'y a pas de live CD pour les versions de test.
Il y en a parfois pour les versions finales :
http://fedoraproject.org/wiki/Kadischi/LiveCD

Le live CD sera peut-être "officiellement" supporté via le projet stateless (un projet très ambitieux et qui ne se met pas en place en 2 semaines) :
http://fedoraproject.org/wiki/StatelessLinux

Avec stateless il sera possible de faire un live cd depuis la distribution (qui intègre KDE ou Gnome ou seulement la ligne de commande, etc).

[ Répondre ]

> Si j'ai bien compris test = RC pour Fedora

Et non :-)

Le processus dans les grandes ligne de Fedora :
- test 1 : la premier version disponible, beaucoup de bugs, la liste des fonctionnalités n'est pas arrêtée.
- test 2 : moins de bug, gel des fonctionnalités principales jusqu'à la version finale.
- test 3 : encore moins de bug, gel de toute les fonctionnalités, uniquement les corrections de bug sont accèptées. Gel des chaines de caractère pour traduction.
- finale

En gros entre chaque version il y a 4 à 6 semaines.
La "test 3" n'est pas une RC car elle n'est pas encore considéré satisfaisante pour être potentiellement une finale.

Il y a eu des RC (semi-officielle) chez Fedora. En générale c'est 1 à 2 semaines avant la sortie de la finale. Elles sont semi-officielle car il n'y a pas d'annonce public. Elles ne sont pas secrètes, elles sont seulement annoncées sur les mailings test et devel (qui sont publics).

les test * ne sont pas des RC car il n'y a aucune garantie de pouvoir mettre à jour une test n vers une test n+1, ni une test vers la finale. Si ça marche alors tant mieux, sinon tant pis.

S'il faut une anologie :
test 1 => alpha
test 2 => beta 1
test 3 => beta 2
RC optionelles => RC
finale => finale

[ Répondre ]

> S'il y a des présomptions fortes, oui.

Une présomptions de quoi ? On ne sait pas. On nage en plein délire.

D'avoir des bugs confidentiels ? Ce n'est plus une présomption ça été "avoué" au moins 100 fois sur les mailings de Red Hat et avant ce skud de mosfet.
Et oui, on n'a pas besoin d'un journaliste d'investigation de cher Mandrake pour le savoir. Parfois il y a des bugs privés qui dépendent de bugs publiques (cette dépendance est enregistrée par bugzilla) et "hop" on le sait qu'il y a des bugs privés. Même pas besoin de le faire exprès.

> Et je pense que les modérateurs sont capables d'accepter ce genre d'article.

Si c'est anti-Red Hat mais surtout pas anti-Mandr*, ils en ont fait la preuve et c'est consternant alors qu'ils arrêtent pas de nous bassiner sur le travail d'investigation des modérateurs pour s'assurer de la qualité d'une news, etc... pour finalement sortir une dépêche dont la source est mosfet (trolleur anti-redhat de réputation inter-planètaire) et relayé par un employé d'une boite concurrent à Red Hat.
Quand on accèpte ça, on accèpte tout. Bizarre, quand les dépêches sur Red Hat sont positives les modérateurs sont plus sélectifs (je le sais trèèès bien).
Consternant.

> Ca parait une explication plausible

Ce n'est pas plausible, c'est la bonne explication.
S'il y avait une volonté de dissimulation, ils n'auraient pas foutu des bugs privés sur un bugzilla public. Ou alors il aurait ajouté deux ou trois patchs à bugzilla pour que ça passe inaperçu. De plus ils n'auraient pas laissé ça comme ainsi durant des années ! J'ai découvert ça en 1998 ! Le dépêche est de 2002 et ça toujours comme ça (on est un 2006 pour ton info).
S'il y avait une volonté de dissimulation, ils feraient comme Mandriva : Système inaccessible et les employés qui n'en pipent pas mot.


> c'est juste dommage que Chaperon ne rende pas ça plus clair sur leur système de bugtracking..

C'est un truc dont tout le monde se fout car c'est privé. Tout le monde conçoit qu'il y a des domaines privés. Qu'on ne puisse pas fouiller tous les ordinateurs de Mandriva ne soulève ni surprise ni interogation chez moi. Et toi ? C'est un truc dont tout le monde se fout et dont tout le monde conçoit instantannément les raisons légitimes. Il y a tout les 3 ou 4 mois une question sur ça sur les mailings de Red Hat, la réponse arrive dans les 20 minutes et l'affaire est bouclée sans le moins drame, sans personne que ça démange de faire une dépêche en première page d'un site populaire avec un troll naze toutes les lignes, avec des interprétations bidons toutes les lignes.
Ca fait depuis des années que linuxfr (dans son ensemble) vomit sur Red Hat. Mais au final il y a quoi ? Pas le début d'un embryon de "smoking gun" pour Red Hat, et plein de gens endoctrinés sur linuxfr[1].
Et pour SuSE c'est pire.

> Je ne sais pas comment ça se passait avec les bugs "Corporate" il y a deux ans et demi

Mais il n'y a pas que pour la Corporate. Avant la Corporate Mandrake *DEVAIT* faire ça.

Mandr(ake|iva) fait comme Red Hat mais n'en dit rien. Red Hat n'en fait pas un secret d'état et c'est eux les "méchants", c'est eux qui "se cache" selon toi. Etrange non ?
Toi le journaliste d'investigation de chez Mandrake, il ne t'est pas venu une seconde à l'esprit de te demander comment ça se passe chez Mandrake ? Il ne t'est pas venu à l'esprit que si Red Hat avait des raisons d'avoir des bugs privés, alors Mandrake qui fait le même boulot que Red Hat avait peut-être aussi des raisons de le faire ? Pour l'investigation c'était facile, t'était chez Mandrake ! Alors que tu croyais obtenir une info """digne""" de passer en dépêche sur linuxfr, tu n'en a même pas parlé à tes colègues de boulot pour avoir leur avis pour savoir de quoi il en retournait ! A moins qu'ils soient tous abrutit chez Mandr*, t'en aurait trouvé un qui en 2 secondes t'aurait dit que c'est "classique" pour une entreprise qui a des clients.
Tu ne t'es même posé la question du pourquoi.
Endoctriné par linuxfr tu t'es dit que Red Hat est un méchant et t'était satisfait par cette explication.

Soit t'es naïf, soit t'es con, soit t'es de mauvais fois.

> > Tu n'as pas tord. Mais pour la merde d'article précédant, tu devrais te retenir car ça pue fort.
> > Tu ne trouves pas ?
> Non.

Consternant.

[1] : Ils y en a qui ont "plussé" ta médiocrité.

[ Répondre ]

> Pour Red Hat, c'est vrai qu'ils patchent beaucoup,

Ca me fait toujours sourire cette remarque.
Ca me fait sourire quand c'est tourné en reproche (ce qui ne semble pas être ton propros).
Ca me fait sourire car c'est toujours avancé en étant totalement déconnecté de la réalité, des causes et aboutissant d'un patch.
Ca peut avoir l'approbation de ceux qui pensent que Red Hat code comme un porc. Mais ça c'est des conneries. Effectivement il y a toujours une ou deux conneries qui passe dans un patch. Qui ne fait rien, ne fait pas de connerie, à part la connerie de ne rien faire.
Un patch en lui même n'est rien de négative. D'ailleurs c'est souvent une correction de bug ou un ajout de fonctionnalité et que très exceptionnellement seulement une connerie.

Prenons un exemple : RPM.
Sous Fedora il n'y a pas de patchs et sous Mandriva il y a plein de patchs. Je serais con de dire "ça craint, Mandriva a plein de patchs pour RPM".
RedHat/Fedora n'a pas de patchs, car RedHat/Fedora maintient RPM. Ils ont un RPM qu'il leur convient. Malheureusement ça ne convient pas à Mandriva et Mandriva patche RPM. Je ne vois ce qu'il y a à reprocher à Mandriva.

Mais en fait, j'ai menti. La situation a changé. Maintenant RedHat/Fedora a plein de patchs (autour de 30) pour RPM et Mandriva moins.
En effet, Red Hat n'est pas satisfait par l'orientation que prend RPM. Temporairement, et car RPM est un enjeux "statégique", Red Hat a décidé de rester à la version 4.4.2 et de réfléchir pausément (voir lentement car la décision traine à venir). D'ailleurs une page a été faite et le "directoire" de Fedora à la question sur la table :
http://fedoraproject.org/wiki/rpm-devel
http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-b(...)
Mandriva en est à la version 4.4.6 ou 4.4.7.
La situation est très complexe et sallement confuse. Il y a aussi une histoire de changement de licence de rpm avec un passage de GPL à LGPL qui est loin de faire l'unanimité. Les jugements à l'emporte-pièce sont ici à banir. SuSE aussi reste actuellement à la version 4.4.2.
Des rencontres ont eu lieu entre les distributions qui utilisent rpm (notament RedHat/Novell/Mandriva). Je ne sais pas si des décisions en sont sorties.

> Pour Red Hat, c'est vrai qu'ils patchent beaucoup,

Non, c'est une légende.
Gentoo est peut-être la distribution la plus patchée.
Red Hat a globalement peu de patch mais souvent quelques gros patchs.
Regardes le noyau de SuSE ou Mandriva, ils sont beaucoup plus patchés (aussi bien en nombre de patchs quand nombre de ligne).
La "philosophie" de Red Hat est d'ajouter de grosses fonctionnalités, qu'il développeur souvent eux même, et de les mettre upstream. Mais pour quelles soient upstream, il faut les tester. D'où les patchs puisque les tests sont faits avant que les patchs soient upstream. C'est comme ça pour tout le monde.
A l'opposé, la "philosophie" de Mandriva est plus portée sur la "finition". L'ajout de driver, etc, qui fait le bonheur de l'utilisateur.
Les deux démarches ont leurs atouts.

Et puis merde, n'es-ce pas la force du logiciel libre de permettre à chaque de l'accomoder comme il lui convient.

[ Répondre ]

Toutes les applis Gnome depuis Gnome 2.14 (le boulot a été fait dans Gnome 2.13). Gnome-media, gnome-applets, gnome-volume, totem, etc.

[ Répondre ]

> Il y a ceci aussi : http://linuxfr.org/~tanguy_k/22063.html

Et alors ?
Ce n'est pas une réécriture de Dbus. C'est l'encapsulation de dbus (les même sources que ceux de freedesktop) dans Qt.

> Et pour confirmation, lis donc le descriptif de cette présentation de l'aKademy (fin de ce mois) : http://conference2006.kde.org/conference/talks/27.php

Ca ne change rien. Tu devrais le relire attentivement.

> Et si mes souvenirs sont bons, chez KDE, ils veulent une compatibilité source à travers toute la version majeure.

Gnome ne l'exige pas.

> Je commence même à me demander ce que Kde 4 va utiliser d'extérieur sans les wrapper

wrapper est différent de refaire l'implémentation.

Au-dessus il y avait :
- "Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne. La force de dbus, c'est donc : un serveur + une spec de communication et maintenant deux implementations de la partie client."

Il n'y aura qu'un implémentation de la partie client. Mais celle-ci aura un "binding" qt/c++ pour les développeurs qui le veulent.

[ Répondre ]

Et comme d'habitude, les modérateurs n'ont pas corrigé la news ou atténué sa teneur.

[ Répondre ]

> « Avertissement : je tiens à préciser que je suis développeur chez Mandrake donc je ne suis pas forcément très tendre avec Red Hat, ceci dit cette dépêche ne contient je crois que des faits vérifiables et non ambigus. »

Certe. Mais tu crois que les modérateurs devaient laisser passer ça ?

Le bugzilla (ou équivalent) de Mandriva pour les entreprises n'est sûrement pas public (j'espère que tu vas le confirmer ou prouver le contraire).
Tu crois que je devrais faire une news avec "Mandriva se cache" en titre ?
Si je la fais, tu crois que les modérateurs doivent l'accèpter ?

Si t'avais fait un rapport de bug et que Red Hat de sa propre initiative l'avait rendu confidentiel, je serais d'accord pour une dépêche. Mais tu ne l'as pas fait et ça n'est jamais arrivé.
Pour info, Red Hat a des milliers (!) de rapport de bugs confidentiels qui viennent de clients payants. Le "point faible" est que Red Hat les met dans un bugzilla public et donc tu sais qu'il y a des bugs confidentiels.
Avec Mandriva on en sait rien car ce bugzilla (ou équivalent) n'est pas accessible.

Les règles de Red Hat en gros :
- Lorsqu'un rapport de bug est rempli par un client payant (via la hotline par exemple ou autre) il est confidentiel. Lorsque tu achetes une RHEL, c'est un engagement de Red Hat. Mandriva doit avoir le même engagement avec leur Corporate Server. Non ?
- Les rapports de bug à l'initiative des employés de Red Hat sont tous publics (qui soit pour RHEL ou non).
- Les rapports de bug pour Fedora sont tous publics. Je crois que celui qui rempli le bug peut demander qu'il soit privé.

Ces règles n'ont pas changé et personne se plaint.

S'il te plait, dis nous comment ça se passe avec Mandriva.
S'il te plait...
S'il te plait...

> maintenant si en tant qu'employé de Mandrake on devait renoncer à parler de faits vérifiables et non ambigus sur un concurrent, je pense que ce serait dommage. mais c'est juste mon avis.

Tu n'as pas tord. Mais pour la merde d'article précédant, tu devrais te retenir car ça pue fort.

Tu ne trouves pas ?

[ Répondre ]

Si c'était écrit dans la "ligne éditoriale" j'aurais aussi aucun (ou presque) problème avec ça.

[ Répondre ]