IsNotGood a écrit 5009 commentaires

bsdiff, je ne sais pas ce que c'est.

Suse l'a fait (ou le fait toujours).
Fedora va le faire :
http://fedoraproject.org/wiki/Releases/FeaturePresto

> les updates, ajouter ou retirer un paquet , etc... c'est LENT!

C'est lent comment ?

J'ai fait un test avec un machine virtuelle (installe mini-mini, kvm en full-virtualisation, périphérique loopback).

[root@rslnvirt ~]# time yum install openoffice.org-draw openoffice.org-math openoffice.org-langpack-fr openoffice.org-calc openoffice.org-impress openoffice.org-graphicfilter openoffice.org-writer
[...]
Transaction Summary
=============================================================================
Install 137 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 184 M
[...]
real 1m58.744s
user 0m28.640s
sys 0m15.213s

Moins de 2 minute pour 184 Mo compacté.

[root@rslnvirt ~]# time yum remove glib2
[...]
Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 90 Package(s)
[...]
real 0m26.932s
user 0m8.586s
sys 0m4.740s

Il y a peut-être plus rapide, mais plus rapide je m'en fous.

Juste un petit exemple.
Longtemps Fedora/Red Hat n'a pas utilisé rpmlint. Puis vers FC3 Fedora a commencé à utiliser rpmlint (projet Mandriva).
Fedora n'a pas "forcké" rpmlint pour ses besoins.
Un rapide grep sur le changelog (Ville Skyttä est un développeur Fedora depuis longtemps, je ne sais pas s'il est employé Red Hat) :
$ grep "Ville Skyttä" * | wc -l
105
$ grep "mandriva" * | wc -l
326
Joli alors Ville Skyttä ne participe que depuis 2006.

Les bugs sont renvoyés en upstream et corrigés en upstream :
https://bugzilla.redhat.com/show_bug.cgi?id=244835
Il n'y a pas de correction locale.

Pourquoi Mandriva ne fait pas ça ? Ou si peu.

Il y a un truc que je ne comprend pas. Ce n'est pas spécifique à Mandriva.

C'est pourquoi les autres distributions bossent si peu avec Red Hat ?
Certes, on va dire que Red Hat ne le fait pas non plus (sauf un peu avec Debian), mais Red Hat est très "tendance upstream". C'est probablement le distributeur (via Fedora notamment) qui bosse le plus upstream, qui s'implique le plus dans l'upstream. D'ailleurs Fedora est relativement peu patcher contrairement à ce que laisser croire son nombre d'innovation (les développements sont faits dans la mesure du possible directement en upstream, évidemment avec l'accord du mainteneur upstream). La majorité des projets Red Hat a leur propre site web et il faut gratter pour savoir que c'est un projet Red Hat.
Il y a des développeurs Red Hat qui bossent principalement sous .... Debian. Et ça ne dérange personne. Par exemple le mainteneur de pulseaudio est un employé Red Hat et il bosse sur Debian.
Red Hat a aussi une "force de développement" qui lui autorise une certain (mais pas totale, loins de la) autonomie.

Alors, pourquoi ne pas bosser plus avec Red Hat ? Je veux dire plus spécifiquement avec Fedora ?

> Il n'y a jamais eu de mini-fork d'udev dans Mandriva.

Mouaiff.
Un première version était une repompe de FC3 (et c'est normal). Puis ça a dérivé et pour la 2008 (si j'ai bonne mémoire), c'est revenu sur ce que fait Fedora.

> Nos patchs qui sont utiles à toutes les distributions sont remontés upstream

Que pouvez vous avoir pour udev qui est vous est utile et ne l'est pas aux autres ?

> mais nous sommes obligés d'en conserver quelques-uns liés aux spécificités de la distribution (packaging, système de détection de matériel).

Packaging : oui.
système de détection de matériel : non.

Et sans froisser Mandriva, la détection du matériel n'a pas été développé par Mandriva. C'est le noyau, c'est udev, etc, mais ce n'est pas Mandriva (ni Fedora).

> Quant à mkinitrd, la plupart des distributions ont leur propre implémentation, et c'est difficile d'isoler un projet "upstream"

Très bonne remarque.

> Nous allons nous rapprocher du mkinitrd Fedora, mais là encore, nous avons besoin d'adaptations à notre packaging,

Très bien.
Avez vous envisagé de passer directement au mkinitrd de Fedora ?
De remonter les problèmes ou limitations que vous rencontrez ?
Avez vous lancé une discussion avec Fedora pour voir si Mandriva pouvait fusionné ses spécificités en upstream ?

> Ce ne sera pas exactement un fork, puisqu'il sera régulièrement fusionné avec la version RedHat

C'est un fork. Désolé.
Vous les remontés quand vos modifs ?
Quasiment jamais.
Lorsque vous faites des modifs, en discutez vous avec l'upstream (qui ici est manifestement le mkinitrd de Fedora) ?
Ben non.

Peut-être, et très probablement, vous avez des idées qui vont plaire à Fedora. Au-lieu de bosser dans votre coin et seulement repomper le boulot de Fedora, bossez avec Fedora.

> Ce n'est pas juste pour le plaisir que nous écrivons des patchs supplémentaires par rapport aux packages de Fedora (par exemple), mais parce que notre politique de packaging est différente, et que nos méthodes de configuration sont différentes.

OK, OK, OK, le packaging est différent. M'enfin, ce n'est pas le bout du monde. J'ai vu des .spec qui marchent pour Fedora, Mandriva et OpenSuse avec seulement une poignée de "if ....".

M'enfin, ton message est "incongru".

D'un côté il y a une annonce pour dire que deux distributions vont faire des choses en commun, et de l'autre tu dis que ce n'est pas possible avec Fedora. Chercher l'erreur...



Tout ça c'est culturel et c'est presque tout.
Si on va sur les mailing Fedora ou projets Red Hat, on ne voit jamais Mandriva (ou hypra rarement). On voit, certe très ponctuellement, du Ubuntu, du Debian et du SuSE.

Si on va sur cooker de Mandriva (je n'y suis plus allez depuis longtemps), on voit beaucoup de référence à Fedora (mais très rarement des développeurs Fedora) avec "synchronisation avec la dernière version Fedora", "patch Fedora", etc.
On voit aussi beaucoup de "Fedora ça pue, on va faire à notre propre sauce".
Le tableau c'est "on ne peut pas se passer du boulot de Fedora ou il nous est très profitable ET on ne veut pas montrer qu'on est lié à Fedora". Je trouve ça ridicule.

Un exemple de ce que j'aimerais voir. Imaginons que Mandriva veut utiliser libvirt/virt-manager. Mandriva évalue et pose des questions en upstream. Mandriva veut faire des modifications. Mandriva pourrait en discuter upstream. Pourquoi Mandriva ne le fait JAMAIS ?

On voit quoi dans ce journal ? On voit que Mandriva et TurboLinux vont travailler "main dans main" pour rpm. Pourquoi ce n'est pas possible avec .rpm.org (ou Fedora) ?

> Un gestionnaire de paquets est le cœur d'une distribution Linux moderne.

Non, non et non.
Si je passe d'Ubuntu à Mandriva je change de coeur ?
Je ne crois pas. Il y a des distributions rpm qui utilisent synaptic par défaut et l'ancien utilisateur de deb ne se rend même pas compte qu'il est passé à rpm avant d'avoir gratté un peu le verni.

C'est un élément très très important pour certains utilisateurs (développeurs, etc).

Mais ce n'est pas plus le coeur que Linux (le noyau), la libc, X11, un système de fichier, etc...

> Même pas toutes les discussions préliminaires se sont faites en interne Red Hat

Tu parles de quoi ?
Oui Red Hat a eu des discussions en interne. Pour embaucher un développeur (mettre du "cash"), tu ne vas pas en discuter avec d'autres. Pour voir s'il est "rentable" de mettre un développeur ou deux sur rpm au-lieu de bidule, tu ne vas pas en dicuter avec les autres.

> avec consultation discrète des autres distributions utilisant rpm.

Il y a toujours des contacts "privés". Mais la consultation a été annoncée très tôt et de façon public. Et en gros on peut affirmer qu'elle a été quasiment ignorée (il n'y a que SuSE qui a donné son soutient à Red Hat pour relancer rpm.org).

Je pense que les messages "privés" ont dû être hypra limité si jamais ils ont existé.

> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.

En passant, toutes les mailing Fedora sont ouvertes.
Avant le départ de Johnson le problème a été posé.

Red Hat n'a peut-être pas été exemplaire, mais que dire des autres ?
C'est marrant cette façon de critiquer Red Hat alors qu'en même temps on attend tout de Red Hat. Les gens n'attendent rien de SuSE (pourtant ils utilisent rpm), rien de Mandriva (pourtant ils utilisent rpm), etc...

> Toutes les discussions préliminaires, après deux ans de silence, le fait qu'ils allaient reprendre leur version, se sont déroulées sur les listes RedHat ou Fedora. Sûrement un signe d'ouverture.

Et alors ?
Red Hat devait s'inviter sur les mailling Debian pour discuter de rpm ? Pour discuter s'il fallait débloquer des fonds pour embaucher ? Pour évaluer en quoi rpm est critique pour le business de Red Hat ?
C'est ridicule.

> Et il l'a fait: rpm 4.4.4, 4.4.6, 4.4.8. Toutes ces versions ont existées avant que RedHat ne se bouge.

Red Hat a bougé. Fedora est resté à la version 4.4.2. Idem pour SuSE.
Ces trucs sont très compliqué à gérer. Rpm est largement utilisé, Red Hat n'allait pas fermer http://www.rpm.org/ et l'accès au CVS de Johnson du jour au lendemain. Il y a eu une transition. Mauvaise car il y avait conflit (ou suspicion)

Enfin, c'est gentil de critiquer Red Hat pour son manque de dynamisme, mais c'est le seul qui a repris les choses en main. Mandriva a rien foutu ni même donné un soutient (d'ailleurs Mandriva est passé à rpm 4.4.8 pour revenir à la branche Red Hat/Fedora).

Qu'au sein de Red Hat on critique la mollesse de Red Hat au début de cette affaire, je comprend très bien. Mais que les autres critiques alors qu'ils n'ont rien fait, je ne comprend pas.


En passant, Jeff Johnson est un excellent développeur qui a fait un excellent travail pour rpm.

> la principale raison est qu'on lui demandait de corriger des problèmes dans RPM sans le faire évoluer.

Que non. Il proposait des évolutions que ne voulais pas son employer. Notons que SuSE a très tôt indiqué que la direction de Johnson ne leur plaisait pas et qu'il resterait, comme Fedora, à la version 4.4.2. Mandriva a fait comme d'hab : ignoré Red Hat/Fedora "officiellement".

Chez Red Hat, il suffit de regarder Fedora, il y a une grand latitude pour l'initiative des développeurs (du moment que les questions prioritaires sont réglées : sécurité, support, etc).
Il n'a pas écouté son employeur, il a été viré. Ou on lui a indiqué avec insistance la direction de la porte. Si j'ai bonne mémoire, lors des 8 derniers mois de Jeff Johnson chez Red Hat, il y avait un fork pour Fedora (d'où Fedora qui est resté à la version 4.4.2 et une grosse pile de patch).

> C'est Jeff Johnson qui est parti de chez RedHat

Il n'est pas parti, on l'a viré. Les choses n'ont peut-être pas été aussi "violente". M'enfin, tu le dis, tout ce qui a fait après 4.4.2 a été pris avec des pincettes.

> D'ailleurs le RPM de rpm.org n'aura plus de changements majeur

Que tu dis.
Et quel changement majeur tu veux ? Que rpm passe à deb ?
Soit plus spécifique.

> et gardera un grand nombre de lacunes. (AMHA)

Quelles lacunes ?
Qu'un truc ne soit pas parfait, ça toujours comme ça.
Compare avec deb (et non apt), et rpm est sans problème aussi bon (voir aussi rpmbuild).

> Les débianneux apprécient aussi surement ce standard qui exclue de fait leur distribution (et ubuntu, et slackware, et gentoo, etc...)

Pourquoi ? C'est un format. Prend le format deb, et t'as le même problème.
Il fallait un format. Il fallait faire un choix, "trancher".
Lsb est surtout pour les ISV (Independent software vendor). Et dans ce domaine l'histoire montre que choisir rpm au-lieu de deb est "normal". Je ne dirais pas que c'était incontournable. M'enfin, deb apporte quoi de plus ? À part le tag "suggestion" ?

> Et en plus ils ne sont pas parti de rpm 4.4.8 qui était le dernier dans le CVS encore commun, mais de rpm 4.4.2.

Beaucoup d'éléments des version post 4.4.2 sont dans la 4.4.2.


L'un des problèmes de rpm, est qu'il roxe. Oui, oui. Oublions tout le FUD, rpm roxe. Il fait son taff et on l'oublie. Trouver des développeurs pour rpm alors que rpm fait l'affaire est "compliqué".

> Exact, IBM étant le seul poids lourd de la phrase initiale.

Pas vraiment lié.
IBM est un "généraliste". Il propose des solutions avec n'importe quel OS et dont du GNU/Linux. Si IBM a Mandriva comme partenaire privilégié, IBM vendra du Mandriva, commandera des développements à Mandriva, etc.
De plus ça "ouvre" l'immense carnet d'adresse d'IBM.

> C'est pas dans un partenariat avec RedHat, Novell et IBM que Mandriva va se faire remarquer!

Tout à fait d'accord (sauf pour IBM).

> le besoin était d'avoir une réponse très rapide à des requètes très simples, ce que les "concurents" ne savaient pas faire

Postgresql c'est faire.

> ils ne savaient que faire moyennement rapide pour tout type de requète

Désolé, mais postgresql est définitivement plus rapide que mysql.

> Benchmark

Dans les benchs comparant Mysql et Postgresql, ce dernier gagne quasiment toujours. Le seul truc, c'est que si le serveur n'est pas chargé, Mysql est parfois plus rapide. Mais avoir une réponde en 0,01 s ou 0,02 s ne change rien. Par contre lorsqu'il est chargé, MySQL s'écroule. Et dans ce cas il y a une différence ontre 1 s et 4 s. En plus PostgreSQL n'est pas plus compliqué (les requêtes "select ..." etc se font de la même façon que Mysql si tu te limites aux fonctionnalité de Mysql), a une superbe doc, respecte la norme SQL, et répond présent s'il faut faire des trucs compliqué. PostgreSQL est même souvent plus simple (excellent gestion des types, il n'y a pas de problèmes avec les dates, etc).

Que MySQL soit (ou était) populaire, je comprend. C'est fournit en standard par les hébergeur, ça existe depuis longtemps sous Windows, etc...

Mais je parle de l'image de MySQL. MySQL est un petit SGBD. Sympatique OK. Un SGBD qui ne fait pas du transactionnel (je parle du "vrai" transactionnel sur plusieurs tables, avec plusieurs requêtes de suite, etc et pas une transaction pour une table), est un forcément un petit SGBD.

Désolé. Mais c'est mieux que d'être traité d'hypocrite, d'avoir des arrières pensées, etc.

Pas de problème ici.
Pour info :
- kernel-2.6.23.9-85.fc8
- java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8
- azureus-3.0.3.4-2.fc8

Ce qui est fournit pour F8.

Pour mon Azureus qui tourne (depuis 1 jours et 1 heure) :
$ lsof -p 10302 | wc -l
348

Pas énorme (notons que ça inclus les connexions réseaux).

> A priori, le fait d'avoir des devs sur place devraient améliorer un tantinet la communication

Je doute que ce "lab" sera localisable géographiquement. Il n'est rien dit sur ce point.
http://www.mandriva.com/enterprise/fr/societe/presse/mandriv(...)

[...] les deux sociétés souhaitent ouvrir leur partenariat à d’autres éditeurs de distribution Linux bases RPM.
[...]
«Ce partenariat stratégique est le premier pas vers la convergence des distributions Linux à base de RPM » a ajouté François Bancilhon, PDG de Mandriva.
[...]

C'est "désespérant" de lire des trucs (pour ne pas dire conneries) pareils...

Moinsez moi, j'ai la flemme d'expliquer à quel point je trouve ça con.

> pour la petite histoire que l'idée n'est pas nouvelle (LSB, DCC, Linux Core Consortium, UnitedLinux,...)

Mandriva a "participé" à LCC. Bilan : fiasco.

Je vais me mouiller, je pense que ça va encore être un fiasco.

> gcc, glibc, rpm, le kernel, bin-utils, mkinitrd, udev.

Ils feraient mieux de bosser en upstream et plus particulièrement pour les deux derniers.
Ça fait depuis des années que Red Hat/Fedora maintient mkinitrd et udev (packaging/exploitation sous Linux pour ce dernier). SuSE fait de même de son côté.
À chaque fois Mandriva fait des "mini-fork" et se synchronise avec Fedora. La dernière Mandriva a foutu son "mini-fork" d'udev pour revenir à Fedora.
Es-ce la faute à Mandriva ou Fedora ?
Qu'importe. On voit seulement que c'est un problème culturel, ou d'objectif, ou de calendrier, etc et non de partenariat.

> Question que je me pose depuis pas mal de temps : tu bosses pour RedHat ou une société partenaire ?

Je ne bosses pas pour Red Hat, je ne fais pas parti d'une société partenaire, etc...

J'ai écrit ici et ailleurs "excellentissime Fedora" pour qu'on me "foute la paix" et éviter les "ne l'écoutez pas, il est pro-Fedora/Red Hat et gnagnagni et gnagnagna". Je préfère dire de suis que je suis pro-Fedora/Red Hat avec ce que cela implique de subjectif/affectif.
C'est mal d'être "passionné" ?

> Bah ta jamais eu le message d'erreur

Non.

> "au secours trop de descripteurs de fichiers ouvert, java ne peut pas gérer tout ça"

En passant, c'est probablement lié à une limite de Linux (le noyau).
Il n'y a que depuis le 2.6 que le nombre de descripteur ouvert est généreux par défaut sous Linux.

Je serais curieux de savoir avec quoi tu as eu ce problème.
Linux 2.4 ?

Si c'est un problème Linux, ce n'est pas un problème java.

> Mandriva le fait depuis bien longtemps (sauf les versions 2005 et 2006)

Le "(sauf ...)" ...
Red Hat/Fedora et SuSE/OpenSuSE le font depuis très longtemps. En gros c'est une distribution tous les 6 ou 9 mois. Généralement 6.
Notons que pour 2005 et 2006 c'était un choix de Mandriva et non des ratards.

> Derby est assez loin de MySQL en terme de qualité et fonctionnalités que l'on peut attendre d'un SGBD.

On peut dire de même de MySQL. MySQL a un vague support de transaction, pas de support pour les languages embarqués, vaguement compatible SQL, pas de hot backup (qui garde l'ensemble de la base de donnée cohérent), pas de vieux, pas de rules, une tenu en charge très moyenne si on compare à PostgreSQL, etc...

Dès qu'on étude techniquement MySQL, ben c'est un SGBD très très moyen.
Avant de répondre, assurez-vous de bien connaitre Oracle ou PostgreSQL voir SQL Server.

En passant, il y a aussi le très bon client Deluge.
Dans mon ordre de préférence (je n'ai pas testé transmission) :
- Azureus
- Deluge
- Ktorrrent

N'importe quoi.

Je trouve ça un peu de la folie pour un gestionnaire de base de donnée qui n'a de bien que sa popularité.
Je n'ai jamais compris que le médiocre MySQL est une image si flatteuse.

> j'aime pas les icônes sur le bureau

Tu peux mettre un lanceur sur le panel et aussi mettre un tiroir avec des lanceurs.

L'"idée" n'est pas de rentrer dans le jeux de qui a la plus gros ou la mieux carrosée, mais seulement d'indiquer qu'un logiciel populaire (populaire n'est pas un synonyme de "plus mieux bien") était disponible en 100 % libre (Azureus marche avec IcedTea).