Aurélien Bompard a écrit 951 commentaires

Le temps de rédaction est proportionnel au temps moyen qu'accordera le lecteur à ton information.

Franchement, ça serait plus simple et plus rapide de remplacer tous ces chiffres par une échelle du type :
1. vraiment beaucoup
2. beaucoup
3. pas beaucoup
4. vraiment pas beaucoup

Je caricature un peu, hein, mais je pense que le problème vient de la demande, pas de l'offre. Si le lecteur à moins d'attention à y accorder, pourquoi "perdre" tout ce temps à peaufiner ? La quantité d'information disponible a augmenté exponentiellement, donc si le nombre de personnes qui y travaille n'a pas suivi la même courbe, le temps accordé à chaque info a forcément baissé. On a rien sans rien.

Malgré la suspicion ambiante, je voudrait souhaiter très sincèrement bon courage à Arnaud L. pour la tâche qui l'attend. Elle est de taille, mais je pense qu'elle n'est pas impossible.
Pour être utilisateur (ou assez proche) des outils "entreprise" proposés par Mandriva (MES, MMC, Pulse2), je peux témoigner qu'ils sont d'excellente qualité. Il y a clairement un ou plusieurs marchés à attaquer avec.

J'espère de tout cœur que la société s'en sortira, puisque c'est de ça qu'il s'agit ici. Ce ne sera probablement plus la même Mandriva que celle que nous avons connu jusqu'à présent, mais à voir certains commentaires ici ou ailleurs ce n'est pas forcément un mal... ;-)

Bon courage Arnaud.

Oui, tu penses aux distribs qui intègrent des patches conséquents comme GRsec, etc. ?

Pour des modifs d'une telle taille, je considère qu'on est dans de l'intégration spécifique à la distrib (mon cas 2.), vu que c'est quand même un choix important de fonctionnalités.

Si le projet upstream est trop borné, un fork est une bonne solution. Mais dans ce cas tu changes d'upstream, tu n'est pas dans le cas où tu dois ajouter des patches à ton paquet.

> Sans oublier que le temps nécessaire à upstream pour être convaincu d'intégrer le patch n'est pas forcément non nul.

Tout à fait, d'où l'intérêt du 1. Et d'ailleurs, parfois le patch nécessite un peu de boulot avant d'être accepté, ça compte aussi.

Si c'est une option de compilation, pas besoin de patch. Si ce n'est pas le cas, alors un patch qui ajoute l'option de compilation me semble rentrer dans le cas 1.

Faut en discuter avec eux, mais à mon avis les mieux placés pour juger de la pertinence d'un patch, c'est le projet upstream. S'il ne veulent pas du patch en l'état, il faut retravailler dessus jusqu'à ce qu'il ait atteint un niveau de qualité suffisant pour être accepté upstream.

Dans ce cas c'est une amélioration générique de l'upstream, on est dans le cas 1.

J'ai l'impression qu'il y a 2 types de patches :
1. des patches qui ne sont pas spécifiques à la distrib : ceux-là devraient être upstream, par exemple pour corriger un bug avant la sortie de la prochaine version
2. des patches spécifiques à la distribution, pour l'intégration : un navigateur par défaut, un thème par défaut, etc.

Ce sont deux cas tout à fait valides d'utilisation de patches, et de toute façon ce n'est pas ça qui posera un problème de compatibilité entre distrib : l'auteur du code gère déjà le 1. et n'a pas à s'occuper du 2.

Au passage, je suis complètement contre, ça sous-entend que réussir à s'adapter n'est pas un progrès.
Parfait exemple de la philosophie occidentale hyper-matérialiste.

Ouais mais avant on pouvait leur dire de retourner jouer dans leur coin avec leur distrib de crypto-communistes. Maintenant, il se sentent justifiés par le soit-disant succès d'Ubuntu.

Au début j'ai pensé que le commentaire était sérieux, donc je me suis dit que j'allais pas répondre. Et puis j'ai vu l'auteur :-)

Tu sais Misc, je crois qu'il y en a vraiment qui pensent comme ça, c'est affolant. Ou mignon.

Il semblerait que ce soit en projet à la OpenDocument Fellowship :
http://www.opendocumentfellowship.com/projects/proposal

Pour l'instant toutes les soluces que j'ai vu passent par un OpenOffice en mode démon...

Peut-être peut-on bricoler quelque chose à partir de odf2html [http://www.opendocumentfellowship.com/projects/odftools] et soit un convertisseur html vers PDF soit l'adaptation de la feuille XSL docbook vers PDF.

Troll mis à part, je trouve que l'inversion de situation est assez amusante. Avant l'arrivée d'Ubuntu, on voyait les Debiannistes réclamer un support de la part des éditeurs tiers, qui ne proposaient que du RPM. Il sont même développé alien justement pour convertir du RPM en .deb.

Maintenant que la pression marketing d'Ubuntu est passée par là, on a l'impression qu'ils se vengent bassement en affirmant que le .deb est le seul format de package, etc.

Je dis pas ça pour le lanceur de trolls ci-dessus, déjà parce que ce n'est qu'un troll sans méchanceté, mais aussi parce que je ne sais pas s'il a connu l'époque pré-Ubuntu, donc bon.

Enfin, l'ironie de la situation est amusante.

Pfiou, à 30 minutes près c'était trop tard !

Tu es probablement échaudé par la discussion précédente ci-dessus, mais juste pour clarifier mes propos : je ne suis pas en train de dire que ton point de vue est pourri. C'est tout à fait valable, je dis juste que mon sentiment est qu'il y a plus de niveaux de complexité que ça. Ensuite, tu fais évidemment ce que tu veux, j'ai rien à dire là-dessus. (c'est évident mais parfois ici il vaut mieux le rappeler)

> Mais pour aller dans ta façon de penser, quand tu achètes un PC avec Windows, peut-être que Windows sera un besoin futur, donc l'acheter en même temps que le PC n'est pas une vente liée...

Non, ce n'est pas ce que je disais. Je distinguais deux types de bonus : un dont j'aurais pas besoin et un dont je pourrais avoir besoin. Windows, c'est clair que j'en aurais pas besoin. Pour reprendre ta comparaison, c'est comme si j'achetais un pc portable avec sortie HDMI. Aujourd'hui, je n'ai rien qui se branche en HDMI chez moi, mais si j'achète un écran (par exemple) qui en a besoin avant la fin de vie du portable, je serais content que le connecteur soit là plutôt que de devoir acheter une extension USB pour le portable, ce qui va faire des fils en plus, des accessoires à transporter et à brancher, peut-être une alim en plus, etc.

Bon, voilà, maintenant ça c'est ma vision et si elle ne te convient pas, c'est ton affaire, je suis pas là pour te convaincre.

OK, j'avais pas compris que tu n'étais intéressé que par la partie "réception". Vu comme ça, forcément.

Par contre, je ne suis pas sûr qu'il faille trancher aussi radicalement en ce qui concerne les "packages". Parfois le "bonus" ne t'intéresse pas du tout (genre "et -10% si vous achetez une lessive de la même marque"), parfois le "bonus" est quelque chose que tu pourrais utiliser, mais pas toute suite. Dans ce cas, pour toi ça revient en quelque sorte à la préparation d'un besoin futur, ce qui est une information intéressante. Ici, si jamais tu cherches plus tard un moyen de rémunérer des projets libres, le service est là. Après tout, si tu souhaites que des gens le fassent pour toi, tu pourrais un jour vouloir le faire pour d'autres, l'hypothèse n'est pas complètement délirante. Auquel cas, c'est une fonctionnalité intéressante, qui ne compte pas à 100% bien sûr, mais pas à 0% non plus.

Enfin, ce n'est que mon avis (chez-moi-ça-marche comme qui dirait)

> Question frais, c'est un peu élevé : 2€/mois + 10% des sommes reçues.

J'ai peut-être pas compris un truc, mais les 2€ par mois ce ne sont pas des frais, c'est ton budget minimum. Donc à la fin du mois, Flattr ne les empoche pas, ils sont distribués aux projets sur lesquels tu as cliqué.
Et si tu ne cliques sur rien, il sont distribués à des œuvres caritatives (je ne sais pas lesquelles d'ailleurs).

Donc les frais de Flattr, c'est juste les 10%.

Personnellement ça m'intéresse surtout en tant que donateur. Je suis tout à fait prêt à affecter 2€ (j'ai même réglé 5€ dans mon cas) à des dons à des projets qui me plaisent. Et sur Flattr il n'y a pas que du logiciel, un des plus gros "projets" actuellement est la publication des archives d'Afghanistan par WikiLeaks.

La morale d'Inception, c'est que si tu mets une VM dans une VM dans une VM, ben ça rame.

Et oui, chaque fonctionnalité est introduite dans une version n et stabilisée dans une version n+1. Sachant que ce sont les retours des utilisateurs qui permettent principalement de stabiliser, ça semble logique.
C'est aussi la philosophie open-source "publier vite, publier souvent".

Pas choquant, quoi.

Les rachats de Edge-IT et de Linbox avaient pour objectif de se tourner vers l'entreprise par le service, ce qui semble une bonne idée. Le résultat est positif, puisqu'on a vu en sortir de beaux produits (MDS & Pulse2).

Si ta définition de "lent" c'est "plus lent que APT", alors oui. Yum est un peu plus lent que APT pour certaines opérations (même si je ne suis pas un gros utilisateur d'APT). Certaines opérations sont tout à fait équivalentes en rapidité, comme la recherche par exemple (yum search / apt-cache search). Mais là aussi pas de benchs, c'est juste une impression.

Cela dit, yum a quand même tout un tas de fonctionnalités en plus, donc ça me choque pas. Il y a une vitesse minimum en dessous de laquelle c'est désagréable, mais après si APT met 1 seconde de moins sur une grosse opération, franchement ça me fait ni chaud ni froid.

Ce que tu décris laisse juste penser qu'il y a beaucoup plus de mises à jour sur Fedora que sur Ubuntu, ce qui est totalement vrai.
Il est assez courant d'avoir plus de 200Mo de mises à jour quelques semaines (voire jours) après la sortie d'une Fedora.

C'est parce que c'est amélioré à chaque sortie.

Si le yum de la F13 est très lent, y'a un problème, mais si c'est encore une fois quelqu'un qui avait essayé un Fedora 6 et qui avait gravé dans sa mémoire que yum-c'est-lent, il vaut mieux passer à quelque chose de plus constructif.

La première fois ça prend plus de temps, il me semble qu'il teste la rapidité des miroirs pour prendre le plus rapide vu de chez toi.

Ensuite par contre ça devrait tourner normalement. La lenteur que tu as constatée, c'est avec yum (ligne de commande) ou PackageKit (graphique/Gnome) ?


P.S.: pour les trolleurs, si vous n'avez pas testé avec un yum très récent, vos tests de rapidité ne valent rien.