IsNotGood a écrit 5009 commentaires

N'attendons pas, foutons Kerro en tole.

> EC2 == Amazon Elastic Compute Cloud
> ce sont des serveurs sur lesquels on déploie des images (AMI : Amazon Machine Image).

Mouaif.
Tu peux faire ta propre AMI.
Les AMI ne sont que des archives (on y met ce qu'on veut). Ça devient un OS utilisable par une instance EC2 lorsque c'est remonté sur S3 et renseigné comme tel.
D'ailleurs mon AMI a "bêtement" été faite à partir d'une de mes machines virtuelles qui tourne sur ma bécane.
Actuellement le seul problème est qu'on doit choisir un noyau/raminitrd dans une liste (mais assez étoffée). C'est le service EC2 qui lance/charge le noyau et raminitrd. Tout ce qui a après, c'est toi qui décide.
On ne peut pas actuellement faire le noyau qu'on veut utiliser (mais on peut toujours compiler et charger des modules).

> La différence avec une machine dédiée, c'est qu'il n'y a pas de stockage

En fait il y a stockage. Il y a une machine virtuelle (ce qui inclus CPU, mémoire, disque, etc). Le problème est que si tu arrêtes ta machine virtuelle, tu perds le CPU, la mémoire, et aussi évidemment le disque. NB: on paye l'utilisation à la minute de EC2. Si tu arrêtes de payer, tu perds tout. C'est bien normal.
Maintenant on peut acheter séparément la machine virtuelle (avec un disque pour au moins booter) et d'autres disques. Donc si tu arrêtes ta bécane sous EC2, tu peux garder les disques que tu as acheté séparément (mais il te faudra une machine EC2 pour y accéder).

En passant, l'ancienne autre limitation d'EC2 était l'adresse IP. Avant il n'y avait que des adresses dynamiques. Maintenant tu peux aussi acheter une adresse ip static.

> - S3 == Simple Storage Service ( http://aws.amazon.com/s3/ )
> c'est le service de stockage qui est monté dans les instances des images AMI

Pas vraiment. Les AMI sont stockées sur S3 (faut bien les stocker quelque part).
S3 est un service de stockage qui n'est pas lié à EC2. On peut utiliser l'un sans l'autre à l'exception que l'AMI doit être sur S3. Lorsque tu demandes une machine EC2, l'AMI sur S3 est copiée sur ta machine EC2 (tu peux à partir de ce moment supprimer l'AMI sur S3 si ça te chante). Tu peux utiliser S3 avec un navigateur web, avec une API Java, faire de ton espace de stockage S3 un système de fichier (sous Linux ou Windows ou quasi n'importe quoi), etc.
C'est utilisable depuis EC2 et depuis n'importe où (du moment qu'il y a un accès internet).

Il y a un cas particulier, la bande passante et les "transactions" entre une machine virtuelle EC2 et S3 sont gratuites. S'il n'y a que des machines EC2 qui utilisent S3, on ne paye que le volume stocké (très peu cher et avec garanti de service (comme pour EC2 depuis peu de temps)). La communication entre machines virtuelles EC2 est aussi gratuite (avec une belle bande passante en prime).

> =>Ces 2 technos peuvent permettre de suivre la charge TRÈS simplement par rapport à une batterie de serveurs dédiées.

EC2 et S3 sont des services finalement assez basiques. Après on en fait ce qu'on veut. C'est aussi idéal pour faire des tests (puisqu'on paye à la minute).
Mais ça n'a rien à voir avec Google App Engine.
EC2 : machine virtuelle
S3 : stockage
C'est tout.

Des services basiques mais particuliairement bien foutus.

AWS a des services plus ou moins concurrent de Google App Engine. Mais pas EC2 et S3.

> Les AMI sont des images de distributions Linux en général.

EC2 supporte Solaris et Windows depuis peu de temps (et probablement *BSD).

> Et c'est la version 5.2.8 qui est justement dans les ports

Ouf. Ceux qui codent comme des porcs avec magic_quote peuvent continuer.

> Au fait Gparted n' est pas considéré comme super stable à priori, parceque RedHat ne l' a toujours pas intégré par défaut

Ce n'est pas forcément un problème de qualité.
Red Hat cible les entreprises, pas le geek qui installe tout ce qu'il trouve.
En entreprise le repartitionnement est une chose rare. Si c'est pour des serveurs, alors on passe par lvm, et pour lvm Red Hat a system-config-lvm qui est installé par défaut. Et comme un serveur ne sera quasi jamais en double boot Windows/Linux, system-config-lvm suffit.

> plus les partitionneurs des installateurs de RedHat

Ça fait depuis des années que l'installeur de Fedora (et donc Red Hat) est passé à parted (gparted et qtparted ne sont que des interfaces graphiques). Par contre il y a effectivement une interface graphique spécifique dans l'installeur (mais qui au final utilise parted).
Les outils comme gparted et drakdisk n'ont quasiment jamais été la priorité pour Red Hat/Fedora. La priorité a longtemps été lvm/lvm2 et raid lors de l'installation (ce que fait très bien Red Hat / Fedora depuis longtemps). Comme Red Hat veut lvm à tous les nouveaux (par défaut un système est installé avec lvm) il y a system-config-lvm qui peut être vu comme un remplaçant de gparted. Par défaut system-config-lvm est installé, gparted ne l'est pas.

> Meu là tu te trompes... C'est Pirut le remplaçant de up2date.

up2date marche en ligne de commande (comme yum) et en graphique (comme pirut, à la pirut).

> passe à la RH6, oui, elle va déchirer :p

Il n'y a pas de RH6. Il y a (eu) RHL6 et il y aura RHEL6. Oui, je pense passer à RHEL6.

Il me semble qu'il a déjà été répondu à cette question plus d'une fois...
Mais un aspect a été oublié, Yum est en python et la librairie pour accéder à RHN (utilisé par RHEL) est aussi en python.
Autre aspect, Red Hat/Fedora avait up2date. FC1 est sorti avec up2date qui supportait les dépôts RHN (évidemment), Yum, Apt et aussi des simples répertoires avec des rpm.

> utilisé par personne

Il faut bien un début à tout...

> développé de manière indépendante

Et ?

> surtout alors qu'urpm existait déjà et fonctionnait correctement ?

Et smart aussi, et apt4rpm aussi.
En tout cas la décision a été largement (voire âprement) débattue sur les mailings Fedora (qui sont ouvertes à tous). Les archives sont toujours disponibles, je te laisse les consulter.
Par contre, urpmi n'a quasiment pas été considéré.
- Yum a été défendu et proposé par le développeur de Yum.
- Smart a été défendu par les développeurs de Smart.
- Apt4rpm a été principalement défendu par des utilisateurs.
- Urpmi ? personne ne l'a proposé. Vérifies les mailings Fedora si tu en doutes.
- Yast n'était pas libre à l'époque je crois.

> Pourquoi jeter maintenant Drakrpm alors que les utilisateurs y sont habitués et qu'il fonctionne pour l'instant mieux que PackageKit ?

Je n'ai pas dit de le jeter maintenant. Mais vu que PackageKit a un bon potentiel, qu'il est satisfaisant sur F10, je pense que Mandriva devrait aujourd'hui penser à y basculer.

> D'ailleurs ce n'est pas avec Fedora qu'il faut comparer mais avec Red Hat Enterprise Linux. Il y a PackageKit ?

RHEL est basé sur Fedora.
RHEL 5 est basé sur FC6 (FC6 et RHEL 5 n'ont pas PackageKit qui d'ailleurs n'existait pas à l'époque).
RHEL 6 sera basé peut-être sur F11 ou F12 (voire plus). Donc RHEL 6 aura PackageKit. Ça ne fait pas l'ombre d'un doute.

> Oui il y a eu un arrêt de la perte de temps de la part des gens de Mandriva travaillant sur mkinitrd qui en avaient marre de ne pas avoir de réponses. Il existe une ML pour mkinitrd ?

Oui, tu as raison, ce n'est pas parfait.
J'ai aussi soumis des patchs à Fedora dont certains ont fini dans /dev/null sans la moindre réponse (dont un patch de 15 jours de boulot...). Les développeurs sont parfois occupés, ou ont c'est mal exprimé, ou ils ont un plan qui rend caduque le patch qu'on propose, etc. C'est la vie.

> et une tentative sur le bugzilla de redhat était restée sans réponse pendant genre un an....

Franchement c'est mal s'y prendre !
Ceci est "parfait" pour une correction de bug, mais pour l'ajout de fonctionnalité ce n'est pas toujours ce qu'il y a de mieux.
En passant, il y a-t-il eu relance ?
Ou est-ce que le "jeu" était de voir combien de temps le ticket allait rester sans réponse... ?
Il faut aller sur fedora-devel, dire quel est ton objectif, joindre un patch initial, etc.
Si tu veux savoir qui est le mainteneur pour le contacter, ce n'est pas compliqué, il suffit de regarder le changelog (ce que tu as fait il semble).
Il ne faut pas considérer que Fedora (idem pour d'autres) est à la botte de Mandriva et que Fedora se fera une fête de voir un ticket sur bugzilla.
Il faut jeter un pont de communication, mettre des bases gagnant-gagnant. C'est facile si on est dans cet esprit. Si on n'est pas dans cet esprit, c'est l'échec assuré.
Si Mandriva va sur la mailing fedora-devel et annonce qu'ils veulent être au plus proche pour mkinitrd ou autres avec Fedora, Fedora sera à l'écoute. Si tout ce qu'attend Mandriva c'est que Fedora sert uniquement de dépôt CVS pour les patchs Mandriva, ben ça ne marchera pas. C'est voué à l'échec.
Il faut mettre de la compréhension des deux côtés. Pour ça il faut communiquer. Dire ce que l'on veut à moyen terme, débattre sur ce qui sucks (et aussi chez Fedora), etc.
Les contributeurs de Fedora font face à ces difficultés ! Et les contributeurs de Mandriva aussi !
On voit aussi sur les mailing Fedora des développeurs Red Hat qui sont renvoyés à leurs cher études.

> je l'ai envoyé par mail à Peter Jones qui l'a appliqué de suite ( http://git.fedorahosted.org/git/?p=mkinitrd;a=commit;h=329cb(...) ) donc l'avenir nous dira si ca a évolué ou si j'ai eu de la chance

Essaie de faire le point entre ce qui différencie le mkinitrd de Fedora et Mandriva. Dis ce qu'il y a dans les spécificités de Mandriva que tu penses profitables à Fedora. Dis ce qu'il y a dans les spécificités de Fedora et que tu trouves sans intérêts ou que tu ne comprends pas. Annonces tes idées que tu veux mettre en oeuvre. Mais aussi dis, si tu le penses, que tu veux que le paquet dans Mandriva et Fedora diverge le moins possible pour que ça soit profitable à tout le monde. Si globalement il y a entente, et que tu n'es pas un manchot :-), tu auras un accès au git.


Qu'on se comprenne, si je prenais les développeurs de Mandriva pour des boulets, je ne leur demanderai pas de participer en upstream (projets sur Fedora ou non).

Prend plymouth (le nouveau "truc" graphique). Si Mandriva veut l'intégrer à sa distribution, ce qui pourrait être fait, c'est faire une étude préalable (impacte sur les scripts de boot, nouveaux besoins, etc). Ceci étant fait, aller sur fedora-devel, se présenter (!), dire ce que veut Mandriva (est-ce que les nouvelles fonctionnalités peuvent être upstream, voire si les développeurs y travaillent déjà, voir si çà colle avec le planing de développement de plymouth), etc.
Il ne faut pas seulement considérer Fedora comme un CVS.

rpmlint initialement développé par Mandrake est maintenant beaucoup utilisé par Fedora et aussi maintenant beaucoup développé/maintenu par un contributeur Fedora (Ville ...). Fedora y gagne, Mandriva y gagne. On peut aussi avoir des projets actuellement principalement développés/maintenus par Fedora être maintenu par des contributeurs Mandriva.


> Oui il y a eu un arrêt de la perte de temps de la part des gens de Mandriva travaillant sur mkinitrd qui en avaient marre de ne pas avoir de réponses.
> Parce que les patchs soumis par mails au dev restent sans réponse
> une tentative sur le bugzilla de redhat était restée sans réponse
> le pessimisme d'un collègue qui a essayé dans le passé d'envoyer nos patchs sans réponse
> l'avenir nous dira si ca a évolué

Au moins la démonstration est faite qu'il y a un apriori...
"Merci".

> Oh sacrilège, Mandriva a osé prendre une décision differente de celle de Fedora/Redhat !

C'est marrant cette obstination à fermer les yeux...
Que Mandriva prenne une décision différente de Fedora/Red Hat, on en a rien à foutre.
Mais quasi systématiquement Mandriva prend le contre pied de Red Hat si ça lui est permis. D'autres (dont Ubuntu), ne s'emmerde pas comme Mandriva. Ubuntu reprend NetworkManager (sûr que NetworkManager doit être dans un dépôt Mandriva et qu'il a été généreusement porté par un contributeur, moins sûr que Mandriva veut en faire l'outil de configuration réseau par défaut pour garder ses drak*). Ubuntu reprend libvirt/virt-manager, Mandriva continue avec ses solutions maisons qui n'ont de succès que chez Mandriva. Probablement qu'Ubuntu va adopter PackageKit avant Mandriva... PackageKit qui est déjà adopté par Suse (il sera par défaut).
Les ressources d'Ubuntu sont bien moindre que celles de Fedora/Red Hat ou Novell et Ubuntu en prend compte (parfois de façon grossière, mais c'est une autre histoire). Mais pas Mandriva...
Par ses choix techniques (et non de communication) Ubuntu est modeste/raisonnable. Pas Mandriva.

> Alors que tout le monde le sait, Redhat/Fedora c'est la réference absolue de la perfection des distributions Linux

Puisque tu le dis...
Fedora n'a jamais prétendu être la distribution de Madame Michu ou avoir une finition nickel. Vu ses objectifs ce n'est pas tenable et donc Fedora n'a pas la folie d'orienter sa communication dans ce registre.
Pour RHEL, c'est une distribution orienté entreprise qui sort tous les 2 voire 3 ans (les 3 ans seront probablement dépassés entre RHEL 5 et 6). C'est une fréquence beaucoup trop basse pour le geek qui fait le buzz sur la toile.

> C'est toujours pareil avec toi, "Mandriva a fait truc, alors que Redhat a fait truc, ils sont vraiment nuls chez Mandriva, ils font pas comme chez Redhat qui eux sont vraiment parfaits".

C'est toujours pareil avec toi, Mandriva est parfait. Mais Mandriva se casse la gueule. Tu m'expliques ?
Ah oui, les méchants financiers qui ont eu la bêtise de venir au secours de Mandriva qui se fait des croches pieds tout seul.

> C' est dommage, parcequ' il faut bien constater que yum n' est toujours pas à la hauteur e urpm pour gérer rpm

Tu peux argumenter ?

> Quiconque utilise et connait assez bien les deux peux le constater : URPM reste supérieur à Yum pour une utilisation quotidienne.

Tu peux argumenter ?

> tiens au fait c' est quoi l' algo de compression des rpm chez fedora maintenant...

Comprend pas la question. Les paquets sont toujours compressés et ça n'a rien à voir avec Yum ou urpmi.
En passant, les dépôts Yum sont aussi compressés (ce que doit faire tout le monde).

On tourne en rond...

> Ou alors pourquoi ne pas avoir utilisé smart ?

Et si Fedora utilisait smart, on aurait dit "pourquoi ne pas avoir utilisé Yum ?".
On tourne en rond...
Yum a été choisi car :
- Yum est écrit en python et c'est un language qu'utilise beaucoup Red Hat. Par exemple l'installeur (anaconda) est écrit en python ce qui a permis d'intégré Yum à l'installeur.
- Yum utiliser librpm (et rpm-python) au-lieu de réinventer la roue. La résolution des dépendances est en grande partie faite par librpm. La transaction de test que fait Yum, est en faite seulement faite par librpm...
- La philosophie de Yum correspond à la philosophie de Red Hat/Fedora. Pas de millions d'options, une configuration par défaut intelligente. Avec yum par défaut le cache est toujours contrôlé et mise à jour si nécessaire. Ce n'est pas (ou n'était pas) le cas de urpmi ou apt. Yum ne cherche pas à utiliser des astuces "dangereuses" pour installer à tout prix un paquet (comme par exemple smart qui peut downgrader un paquet pour en installer un autre ce qui est dangereux).

Lorsqu'il a été choisi (pour la sortie de FC1), les débats ont été ouverts et très très animés. Les deux "finalistes" était Yum et Smart. Yum a été choisi.

> non mais sérieux, dans le bon timing pour quoi ?

Il y a du subjectif ici.

> tu le dis toi même, packagekit n'est pas pret

Pas prêt pour quoi ?
Pour Fedora et ses utilisateurs qui sont "aventureux" il est prêt. Si PackageKit merde, les utilisateurs sont indulgents car ils savent que Fedora est aussi là pour expérimenter de nouvelle technologie et ils savent qu'ils peuvent se rabattre sur Yum.
Par contre pour une distribution de "neuneux" ou de "consommateurs", PackageKit n'est pas prêt (où l'est depuis peu de temps).
Mais, en passant, il faut bien casser des oeufs pour faire une omelette.

> tu critique mandriva de ne pas l'utiliser alors que mandriva a urpm qui lui est pret depuis pas mal de temps déjà...

Tu ne connais pas PackageKit.
Je te conseille de visiter le site packagekit :
http://www.packagekit.org/

> Pourquoi mandriva devrait utiliser packagekit à la place de urpm ?

Je l'ai déjà dit plus haut. Si Mandriva veut optimiser ses ressources, Mandriva ferait mieux d'utiliser et participer à ce qui est développé par plusieurs au-lieu de développeur seul ses solutions.
Si tu développes seul et veut que les autres te suivent, il faut être très fort (en compétence et ressource). L'histoire n'a pas montré que c'était le cas de Mandriva.

> Pourquoi redhat développe packagekit plutôt que de reprendre / améliorer urpm ?

Premièrement car urpm et PackageKit n'ont rien à voir.
PackageKit est une initiative d'un développeur Red Hat. Il a lancé ce projet sans le support de Red Hat (c-à-d durant son temp libre). Puis finalement la "sauce" à prise, Fedora a supporté le projet (en l'adoptant très tôt) et probablement que le développeur initial de PackageKit à la "bénédiction" de Red Hat maintenant.

> N'est-ce pas plutôt redhat qui préfère déveloper ses softs et ensuite se plain que les autres ne les utilisent pas alors que des alternatives existent déjà ?

Argumentes. Ici j'ai l'impression de discuter avec un type d'extrème gauche...
Red Hat/Fedora a développé/supporté plein de choses, beaucoup sont reprises. Le ratio de déchet est particulièrement faible.

> Je suis également étonné par cette proposition de rendez vous pour faire un AD libre.

Des développeurs de Samba ont été invités par MS chez MS et ils ont trouvé la rencontre très fructueuse.

Il y aura un AD "libre". Red Hat, qui emploie la majorité des développeurs Samba, estime que c'est une question stratégique. Les débuts seront pour Samba 4.
C'est stratégique car jamais MS ne va faciliter l'inclusion des machines Linux dans un domaine Windows (c'est de bonne guerre). Ici l'idée est de remplacer les serveurs AD de MS par des serveurs AD Linux (libre) qui supporteront Windows et Linux. C'est très très important si Linux veut entrer dans le desktop des entreprises.

> # uname -r
> 26.6.27-gentoo-r4

Linux 26.6 est sorti !
J'ai trop dormi ces derniers temps.

> Je pense que Ubuntu attire plus de monde parce qu'entre autres Ubuntu a une plus grande visibilité et des utilisateurs plus prosélytes que les utilisateurs de Mandriva (ou de Fedora, ou de Slackware, ou de ... ). La politique de comm' initié par Canonical autour de Ubuntu est une vraie réussite pour Ubuntu. C'est ce genre de politique que n'a pas su mettre en place Mandriva

Je pense que c'est une erreur de prendre modèle sur Ubuntu. Ubuntu n'est toujours pas rentable. Le problème premier de Mandriva est la rentabilité, Ubuntu n'est pas la solution. Ubuntu n'a pas une forte communauté de "solides" contributeurs (le niveau de qualité laisse à désire ces derniers temps semble-t-il). Fedora a une faible popularité, mais une identité claire et (maintenant) comprise. Fedora, et dans une moindre mesure OpenSuse, a une solide communauté de développeurs (c'est très très très important les contributeurs !). D'ailleurs Fedora vient d'exploser son record de contributeur (passage de 2000 à 12000 en 2 ans je crois ce qui pose des défis à l'infrastruture).
Si ça continue, dans 2 ou 3 ans, Ubuntu ne sera pas dans un meilleur état que Mandriva.

Certe la com d'Ubuntu est formidable pour la popularité. Mais ce n'est pas assez. Mandrake a été populaire, et ce n'est pas assez. Mais "pire" pour Ubuntu, ça c'est fait avec beaucoup de pognon de brulé. Pas du pognon investi pour le lendemain. La percée d'Ubuntu est formidable, mais elle peut être pondérée.

Autre chose, les deux poids lourd Linux (Red Hat et Novell) ont laissé le champ libre aux distributions "pour les masses" (et donc notamment à Ubuntu). Fedora et OpenSuse ne sont pas en concurrence directe avec Ubuntu ou Mandriva. Officiellement Red Hat dit ne pas s'y intéresser au moins jusqu'en 2010. Mais ça ne va peut-être pas durer indéfiniment. Si Red Hat ou Novell décide de changer d'avis, ça peut faire mal. Dans cette hypothèse, les distributions orientées que "desktop" (Ubuntu compris) ont du soucis à se faire et la solution est loin loin d'être facile à trouver.

Si Red Hat et Novell continuent de laisser le champ libre aux distributions "pour les masses", la position de Mandriva n'est pas désespérée sur ce marché. Mais encore faut-il que la direction de Mandriva en est conscience ce dont je ne suis pas sûr.
Le plus gros potentiel de Mandriva c'est ... le succès actuel d'Ubuntu. Les gens se lasseront d'Ubuntu. La distribution est "simpliste" pour caricaturer. Ubuntu aura aussi, probablement, des soucis financier et tout sera moins rose. Ces utilisateurs pourront "naturellement" aller voir chez Mandriva (puisqu'il n'y a plus Xandros, etc). Mandriva cible grosso-modo le même public mais en plus technologique. Ça sera comme une sorte de montée en gamme de passer d'Ubuntu à Mandriva. Touver des solutions pour faire entrer de l'argent ne sera pas facile. Mais au moins, il n'y aura plus une concurrence "déloyale" face à Ubuntu puisque Ubuntu aura les mêmes problèmes que Mandriva.

De la com il en faut. Mais le "matraquage" n'est peut-être pas la solution. Mandriva doit travailler sa communication pour donner une identitée claire. Les déçus ou blasés d'Ubuntu viendront à Mandriva si Mandriva n'est pas qu'un Ubuntu bis.

> - l'affaire Mandrake / Mandriva n'a pas aidé, visiblement le rachat de Conectiva et l'intégration de leurs équipes semblent être mal passés auprès de certains ;

Ajoutons aussi les trucs comme CDD (j'en ai quasiment tout oublié...) ou l'association avec TurboLinux pour un "noyau" de distribution qui n'apporte rien (du moins dont je n'ai quasiment aucun écho), etc.

> Rappelle moi pourquoi créer yum alors qu'il existe urpm ?

Je répète encore cette vérité que j'ai déjà répété 50 fois (ici et ailleurs), Yum existait lorsque Fedora a choisi Yum. Fedora cherchait un remplaçant à up2date. En passant, il n'y avait pas Yum et urpmi, mais il y avait aussi smart et apt4rpm/synaptic. Alors arrêtez de croire que urpmi c'est (ou c'était) le centre du monde.

> Rappelle moi pourquoi créer PackageKit alors qu'il y a drakrpm ?

Va sur le site de PackageKit, tu vas vite comprendre.
Est-ce rpmi fait frontend à Yum, smart, apt ou est-ce que drakrpm fait uniquement frondend pour urpmi ?
Est-ce qu'il existe urpmi pour Gnome et urpmi pour KDE ?
Etc.

> La liste des outils que n'a pas voulu reprendre Fedora alors qu'ils étaient déjà disponibles ailleurs est tellement importante que tu as atteint le niveau de ridicule maximum.

C'est toi qui est totalement ridicule.
Fedora a pris Yum, Yum existait !
Drakrpm est un truc minable à côté de PackageKit alors que PackageKit est tout récent.
OpenSuse prend PackageKit et pas ce pourri Drakmachin. OpenSuse sont aussi des cons ?
Fedora voulait depuis longtemps remplacer init bien avant qu'Ubuntu fasse Upstart. Comme Fedora a trainé pour faire quelque chose, Fedora a pris Upstart d'Ubuntu et développe en upstream.

> Qui donc a diaboliser les outils de Mandriva ?

Ce n'est pas le propos.

> Ils étaient si mauvais ?

A l'époque peut-être pas, je n'en sais rien. Mais maintenant urpmi est largué.
Mais à l'époque, et je le répète encore, il y avait yum (NON CRÉÉ PAR FEDORA), urpmi, apt4rpm et smart !
Pour FC1, Fedora fournissait up2date (normal), yum (par défaut), smart et apt4rpm. Yum, smart et apt4rpm sont toujours présent dans F10...


Mais restez braqué, vous irez pleurnicher dans les jupes des financiers, vous direz que Mandriva était le top du top mais incompris du reste du monde. Une jolie fin. Mais une jolie fin, aussi mignonne soit-elle, reste une fin.

Changez rien, c'est comme ça qu'on vous adore.

> Pourquoi fedora n'a pas repris les packages urpm* depuis longtemps ?

Par exemple car urpm* est en perl et Red Hat/Fedora utilise principalement du python. Car urpmi a une ligne de commande avec 40 000 options alors que Fedora préfère ce qui est concis. NB: il semble que le "bordel" des options de urpmi ait été corrigé.
En passant, Fedora a pris Yum, et Yum n'a pas été développé par Fedora, Fedora n'est pas à l'origine de Yum. Lorsque Yum a été chosi, ça pouvait être Yum ou urpmi (ou aussi apt4rpm/synaptic ou smart qui étaient et sont toujours dans Fedora). Ben ça a été Yum.
Mais qu'importe. Red Hat peut se permettre de développeur un urpmi ou un yum ou un up2date "from scratch". Mais es-ce que Mandriva peut encore se le permettre ?
Red Hat/Fedora peut se permettre de développer libvirt. Mais est-ce que Mandriva peut se permettre de développer drakvirt (ou autre) ?

> Ha vi, mais c'est plus facile pour redhat de redevelopper leur truc

Je répète, lorsque Fedora a pris Yum, Yum existant (ainsi que urpmi, apt4rpm, smart, etc). Yum n'a pa été développé à l'origine par Fedora. En passant, le site de développement de Yum n'est pas et n'a jamais été chez Fedora ( http://linux.duke.edu/yum/ ), le mainteneur et developpeur principal de Yum n'a jamais été un employé de Red Hat/Fedora.

> et ensuite de critiquer les autres de ne pas l'utiliser

Red Hat/Fedora n'a jamais fait cette critique, c'est moi qui l'a fait.

On peut rester au pays de bisounours et dire que Mandriva fait tout tout bien et que rien n'est critiquable dans ses choix. Mais c'est un fait, Mandriva ne cesse de se casser la gueule. Et dire que c'est que de la faute des méchants financiers (comme s'ils étaient responsables du département R&D ou de la communauté des développeurs...), c'est très très léger.

> Combien d'heures de developpeur vont être perdues à maintenir PackageKit au lieu de urpm* ?

Drakrpm est déjà largué par PackageKit après seulement 1 an de développement.
PackageKit n'est pas en perl pourri, il est écrit en C.
PackageKit ne remplace pas Yum, mais Yumex ou autre frondend à yum (ou urpmi ou apt ou smart, etc).
Mais si Mandriva se trouve si supérieur à tout le monde, ben qu'il garde urpmi. Je dis ça, c'est pour Mandriva, sinon je m'en torche le fion.

> Les querelles de clochers, c' est toi qui t' y raccrochent, ici, hein.

Tant mieux si tu as raison. Et comme je l'ai dit plus haut, je trouve Mandriva moins "con" ces derniers temps.
Mais un exemple en passant, lorsque le mainteneur de rpm (j'ai oublié son nom) a été viré par Red Hat, Red Hat a annoncé ne pas vouloir la direction qu'il donnait à rpm et donc Red Hat a fait un fork (ou l'inverse, c'est selon). La position de Red Hat était délicate car Red Hat se retrouvait sans développeur spécialisé sur rpm !
Ben, "comme par hazard", Mandriva a annoncé adopter rpm5.org et a sortie une distribution avec la branche que ne voulait pas Red Hat.
Mais maintenant que Red Hat a mis les moyens en embauchant 2 développeurs et que maintenant ils sont productifs (voir rpm 4.6) ben Mandriva revient à la branche Red Hat...
Pas merci à Mandriva pour le soutient envers Red Hat pour une pièce maitresse d'une distribution alors que Red Hat y a fait sans problème 95 % des développements.
Mais merci à Novell qui a annoncé très tôt soutenir la position de Red Hat.

Mandriva a plein de forks de Fedora. Un fork pour mkinitrd, un autre pour sysinit, etc. Ce sont des "faux-fork", dans le changelog il y a souvent "sync with Fedora/upstream". Ben il n'y a pratiquement jamais de proposition de patch de la part de Mandriva ou de proposition d'idée. Sur la mailing cooker il y a des trucs comme "remove crap Fedora stuff", etc.
Tout ceci est de la bêtise profonde. C'est pire qu'entre Ubuntu et Debian..

> Pour ton info, par exemple, Mandriva et Fedora font stand commun à la fête de l' huma.

Tant mieux.

> Quant à ton hypothétique diabolisation de RedHat, je ne l' ai jamais vu ni perçu...

Pourtant il y avait bien un gus de chez Mandrake qui publiait ici (sur dlfp) des news qui descendaient Red Hat en flamme... Je me rappel par exemple d'un titre : "Red Hat le nouveau MS ?". Un autre devait être "le côté obscur de Red Hat". Etc.

> Les querelles de clochers, tu sembles être le seul à les mettre en avant.

Je crois que tu te trompes.
Je ne les mets pas en avant pour empêcher la collaboration entre Mandriva et Fedora, mais pour expliquer pourquoi cette collaboration n'est pas aujourd'hui (ou hier si tu veux) ce qu'elle devrait être. On voit pratiquement jamais un type Mandriva sur les mailing Fedora. On voit parfois des gens d'OpenSuse sur les mailing Fedora (ou pour NetworkManager, etc).
Il y a mon discours (querelles de clochers) et le discours "officiel" de Mandriva : - "Il n'y a pas de problème avec Fedora, ce n'est pas de notre faute si Fedora ne fait que des choix à la con". Désolé, mais c'est très faux-cul de la part de Mandriva.

Certes, les choses d'arrangent. Mais diable que c'est long...

Tant mieux. Mais si je lis bien, ce n'est pas par défaut.
Fedora utilise PackageKit par défaut depuis F9. Ceci dit, pour F9 il n'était pas satisfaisant. Pour F10 c'est OK.
Si Mandriva en fait son packageur par défaut pour Mandriva 2010, elle sera dans le bon timing à mon avis vu sa cible (Fedora se veut plus "rock and roll" pour l'expérimental).

Ajoutons que Mandriva a toujours voulu ne rien prendre de Red Hat qui a été largement diabolisé ici (en France). Ce ont des querelles de cloché dont le nouveau venu se bat les couilles. Ubuntu est un fork "permanent" de Debian et pompe des trucs de Fedora principalement. Mandriva veut tout faire et quand les ressources sont limités, c'est un peu con.
Maintenant il y a PackageKit développé initialement par Fedora (qui sera dans OpenSuse). Combien de temps ça va prendre pour Mandriva de reprendre PackageKit ? Combien d'heures de developpeur vont être perdues à maintenir drak_je_ne_sais_quoi ?

Question de licence. Comme il y en a qui bosse sur Linux car Windows est proprio.

Enfin Gnome est un projet communautaire, pas un projet uniquement porté par une distribution pour une distribution et pour ... faire moins bien que l'existant.

> Quand le chien est malade on lui trouve tous les défauts pour lui cracher dessus et l'achever plus vite...

Je critiquais Mandrake/Mandriva avant que la boite aille mal.
Ces derniers temps ont été moins catastrophique, voire bon. Mais avec la concurrence d'Ubuntu, l'omniprésence d'Ubuntu, ce n'est pas assez. Comment Mandriva peut attirer des nouveaux s'ils n'arrêtent pas d'entendre "Ubuntu ! Ubuntu ! Ubuntu ! Ubuntu !". Bref, Mandriva se retrouve qu'avec des vieux (désolé).
Côté contributeurs, et surtout nouveaux contributeurs, c'est Fedora et OpenSuse qui ont fait le plus de mal à Mandriva. Ces derniers ont su se renouveller alors que Mandriva pas. Ajoutons à ça des choix techniques pas très futés... Comme faire drakvirt alors qu'il y a virt-manager, etc.

Cette vidéo n'est plus disponible suite à une réclamation de Twentieth Century Fox pour atteinte aux droits d'auteur.

Et merde.