En parler, c'est le rendre interessant, donc autant en parler autant que l'autre qui fait son blog pourassassiner les distribution (bergere ou un truc comme ça)
Ce qui me fait croire ça :
- il parle de fedora
- il poste deux commentaires à la suite (comme IsNotGood le fait souvent sur linuxfr)
- le journal ce blog et IsNotGood à des réactions très vives sur le sujet donc autant en mettre en commentaire sur le blog
- c'est de l'anglais qui est typiquement écrit par un français :-) (ex : I am not agree)
Enfin bref, je pose cette question simplement parce que je suis curieux de savoir si mon intuition est bonne et j'aimerais bien savoir si je suis un excellent détective.
On pouvait considérer le premier billet comme une intervention maladroite voire naïve mais là, il s'enfonce, c'est même dangereux ce qu'il propose.
The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.
Si toutes les distributions collaboraient un peu plus en upstream, ce serait inutile.
Si on doit partager des informations, des patchs et des rapports de bogues, ça doit être fait au niveau de l'upstream et uniquement à ce niveau-là.
ça n'empêche pas aux distributions d'avoir un espace d'échange pour partager leurs expérience au niveau du packaging, de l'intégration mais ça ne doit pas faire doublon avec l'upstream.
Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
On y croit vachement.
I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world.
FOUTAISES ! Le but du logiciel libre est de fournir une alternative au logiciel propriétaire pas de l'affronter. ça c'est l'objectif des boites commerciales autour du libre que ce soit Canonical, RedHat, Novell etc... Les boites et le logiciel ont des intérêts communs mais nos objectifs ne sont pas les mêmes.
we’re more likely to have the same versions of key components at any given time.
C'est exactement ce qui lui a été proposé dans Debian Common Core et c'est exactement ce qu'il a refusé.
these are items which likely need the most stabilisation and testing before they ship to the innocent
C'est un travail de tout les jours, ce n'est pas en focalisant sur une version précise qu'on améliorera la situation. Pour cela, il n'y a pas de secret, il faut travailler en UPSTREAM.
I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!
On voudrait des noms, parce qu'à part les éventuels développeurs noyaux employés par Canonical j'y crois pas un instant.
Si il est capable de citer les personnes qui ne sont pas d'accord avec lui, il peut très bien faire l'inverse.
we would be able to improve greatly ALL of their support for today’s hardware
C'est le truc qui m'a le plus énervé. En gros, son but est de stabiliser les gros composants des principales distributions pour faciliter le support des pilotes propriétaires.
Alors que la communauté du logiciel libre se bat pour la libération des specs et des pilotes, Mark Shuttleworth lui enfonce un poignard dans le dos.
Et après, il ose dire qu'il soutient le logiciel libre ? Autant ce discours est compréhensible dans la bouche d'un chef d'entreprise, autant c'est inadmissible de la part d'un libriste.
Favoriser les pilotes propriétaires ne feront pas et ne feront jamais avancer le logiciel libre, ça peut favoriser les affaires d'une boite commerciale à un moment donné mais basta.
Mark S. nous propose un modèle propriétaire, seuls les composants sélectionné par les "boites" auront un support matériel correct, les autres devront marcher au pas.
Les constructeurs ne supporteront que les composants sélectionnés (les autres iront se faire foutre), les constructeurs n'auront pas envie de changer de politique vis à vis des pilotes libres (après tout, ça marcherait bien comme ça) ça reviendrait à faire un doigt aux autres plateformes libres (*BSD & cie), ils n'ont qu'à utiliser Linousque LTS (la fusion entre Ubuntu LTS, RHEL, etc ...)
Le pire c'est qu'il prévoit d'étendre ça à d'autres composants, c'est à dire à plus moins long terme, la sclérose de GNU/Linux, Il ne faudra plus casser les pilotes et logiciels propriétaires, bref, on finira comme Windows, une plateforme fade et sans innovation, trainant de gros boulets.
On n'est pas encore à ce stade, hein.
Mais ce qui arriverait, si les distributions majeures acceptaient cette proposition de figer les composants majeurs. Aujourd'hui, le nombre de pilotes propriétaire dans Linux est relativement restreint mais si on leur facilite la tâche, ils se multiplieront et on finira par ne plus pouvoir s'en passer. Et quand on sera tributaire des pilotes propriétaires, on sera poings et pieds liés.
On ne pourra plus corriger le noyau ou X ou du moins proprement si on a le malheur de casser un pilote.
Hein, il parle dans un second temps d'étendre ce concept au bureau, vous imaginez le jour ou il faudra faire de gros hacks pour ne pas casser MS Office Linux Edition parce que MS ne prévoit pas de mises à jour avant 3 ans.
Tu peux synchroniser les versions de composantes sans forcément scléroser les projets, ce sont deux choses distinctes.
Si toutes les distribs passent de la version x à la version x+1 d'un composant en même temps, tu facilites la vie des développeurs de pilotes propriétaires car ils n'ont qu'une seule cible à atteindre mais d'un autre coté rien ne t'oblige à conserver la compatibilité pour autant, ça s'est le problème de l'upstream. Et j'imagine assez mal Fedora acceptant de ne pas passer à la version x+1 sous prétexte qu'nvidia n'est pas prêt. Et là je pense que l'on touche du doigt le problème de l'idée de Mark Shuttleworth : comment seront décidé les versions utilisées par tous ?
Ceci dit je pense que la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre. Et s'interdire un truc juste parce que le logiciel propriétaire en profiterait... ça me fait un peu trop penser aux bugs windows présents en apparence juste pour emmerder la concurrence.
Personnellement j'aime bien que les différentes distributions aient des versions différentes, fassent des choix différents. Ce qui m'inquiète le plus dans la solution proposée par le cowboy de l'espace c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
> Tu peux synchroniser les versions de composantes sans forcément scléroser les projets, ce sont deux choses distinctes.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.
> Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Et surtout ils ne bosseront pas sur la version upstream, ils ne participerons pas au projet en upstream.
> Ce que tu appelles difficulté est en fait une force du libre
C'est clair.
Il y a une chose intéressante. RHEL/SLES amène le libre (tel qu'il est, tel qu'il a évolué librement) aux sociétés commerciales dont beaucoup font du proprio. Mais elles n'imposent pas le monde commercial/proprio au libre.
Au niveau du bureau, je ne connais pas KDE, mais sous Gnome, un programme propriétaire ou libre mais abandonné, développé pour Gnome 2.0, est censé pouvoir tourner sans problème sur Gnome 2.22.
Dans cette dernière version, gvfs a remplacé gnome-vfs, mais cette bibliothèque sera toujours présente, justement pour assurer la compatibilité. Puis au sein d'une même bibliothèque toujours en place, telle que Gtk+, même si de nouvelles fonctions font leur apparition et que d'autres deviennent obsolètes, elles seront toujours présentes pour assurer la compatibilité.
Il n'y a que lors d'un changement majeur de version, tel que ce fut le cas de Gnome 1.x vers 2.x, et peut être un jour 3.x, qu'on peut se permettre de faire le grand ménage et casser la compatibilité. J'imagine qu'il en va de même pour d'autres composants majeurs du système.
Tout les composants ne t'assurent pas de compatibilité totale: que ce soit source, ABI (récemment Gecko 1.8 -> Gecko 1.9) ou comportemental.
Même dans GNOME, certains modules ne sont pas garantis comme étant stable au niveau de l'API ou de l'ABI, par exemple GStreamer.
Dans la mesure du possible, on évite de tout casser mais parfois tu n'as pas le choix.
> Dans cette dernière version, gvfs a remplacé gnome-vfs, mais cette bibliothèque sera toujours présente, justement pour assurer la compatibilité.
Très juste.
C'est seulement la gestion de la compatibilité.
Ce n'est pas fixer la date de sorti de gvfs et ses fonctionnalités pour une distribution commerciale.
C'est une différence énorme.
> Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
>
> On y croit vachement.
Biensûr qu'on n'y croit pas deux secondes.
L'un des problèmes est aussi le mépris des forces en présence. Ce n'est pas "force" que dans le sens "celui qui a les plus grosses parts de marché où celui qui rapporte le plus pognon".
Si on prend l'aspect pognon, RHEL (et aussi SLES) gagne haut la main. Mais ses dernières ne vont pas imposer leurs calendriers/désires aux projets upstream ni aux autres distributions.
Pourtant Red Hat ne doit pas manquer de communiquants de talent pour enrober des fadaises du style : "synchronisez vous sur nous (ou 2 ou 3 distributions pour que l'intention soit moins criante), c'est bon pour le logiciel libre".
Red Hat ne le dira surtout pas car :
- RHEL répond à des exigences commericiales (pas aux exigences du libre)
- RHEL "se fout du libre", elle répond aux besoins des clients Red Hat, pas du libre.
Ubuntu est comme RHEL dans une certaine mesure.
Évidemment, Red Hat sera ouvert aux participations externes, accèpte très bien que le libre profite de RHEL (CentOS, etc), voire en est heureux. RHEL est aussi une distribution libre (mais commerciale) et Red Hat a toujours eu un comportement presque exemplaire avec le libre.
La "force" de RHEL pour le développement du libre est quasi nulle. Sauf le pognon que ça génère qui est ensuite en parti mis dans Fedora, développeurs upstream, etc. Mais c'est indirect.
Red Hat pourrait faire le coup de Mark S. avec Fedora. La force de Fedora est le développement et surtout le développement en bonne entente avec les développeurs upstreams. En bonne entente et non dans un rapport de force.
Debian pourrait aussi le faire, mais on touche à des problèmes quasi culturels et d'organisation. M'enfin, de par sa nature non commerciale, Debian est bien placé.
Mais même pour Fedora c'est malvenu. Fedora est aussi la base d'un produit commercial.
L'aide qu'a Fedora de la communauté, des développeurs upstream, Fedora la tient de ses participations au libre. Pas d'un calendrier commercial, pas d'un discours bisounours "c'est bon pour le libre". Fedora se met au service du libre (dans une certaine mesure évidemment mais une bonne et belle mesure). Via l'infrastructure (qui est libre dans le cas Fedora :-)), via des développeurs, etc. Pas l'inverse, le libre n'est pas au service de Fedora. Puis Fedora en tire profit car Fedora fait parti du libre et est dans la logique du libre.
Qu'es-ce qui "dicte" le calendrier de Fedora et ses fonctionnalités ?
Sa communauté qui veut une distribution vivante (donc qui sort souvent, avec le dernier cri du libre), ses objectifs (le développement du libre, rien à foutre si le driver proprio bidule explose), les développements upstream et la participation de Red Hat évidemment. Ce ne sont pas des besoins commerciaux (ou très accessoirement puisque Fedora est la base de RHEL).
On peut dire évidemment grosso-modo la même chose pour OpenSuSE.
On peut aussi le dire pour Ubuntu et Mandriva. Mais nettement moins.
Ce n'est pas une critique de Mandriva. Mandriva assume (aussi bien son choix d'être une distribution (partiellement) commerciale que son faible poid et ne joue le rôle de "nouveau leader du libre"). Si on veut un calendrier commercial, être driver proprio friendly, on assure. On ne demande pas gratuitement la coopération du libre pour vous aider à gagner du pognon.
Évidemment, tout ceci ne dit pas que la coopération est mauvaise. Si KDE aligne son calendrier sur Gnome, ça peut peut-être sympa, etc. Mais assurement, la demande ne doit pas venir de Canonical qui est clairement ici motivé par des enjeux commerciaux.
Donc, où veut en venir Mark S. avec cette magouille. Je fais ici une simple supposition.
Mark S. veut :
1) soit créer à une masse critique (Ubuntu + Debian + ....)
2) soit appartenir à une masse critique (RHEL ou SLES)
Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Pour le 2), ben il y a déjà CentOS, Oracle Linux, etc.
Le but est d'avoir, par exemple, Oracle supporté sur Ubuntu. Il n'y a pas de honte à ça. La méthode employée est par contre très très discutable pour ne pas dire pire.
Je vais parler que d'Oracle et RHEL, mais on peut généraliser.
Si Ubuntu est quasi la même chose que RHEL, Ubuntu va dire à Oracle : "on est populaire, vous avez fait tout le boulot pour RHEL, c'est trois fois rien pour vous de supporter Ubuntu".
Ubuntu pourrait faire une sorte de clone de RHEL (un clone pas aussi parfait que CentOS ou Oracle Linux). Mais les acheteurs ne sont pas dupes, ils savent que l'expertise est chez Red Hat et donc il achète du support Red Hat (du support c'est de l'expertise). L'échec d'Oracle Linux en dit long.
Cette voix doit être abandonnée. Ubuntu tente donc de diluer l'expertise de Red Hat. Ubuntu n'est plus alors une repompe de RHEL, mais Ubuntu et Red Hat des acteurs du noyau d'une distribution utilisée par Red Hat et Ubuntu (et d'autres).
C'est malin (quoique pas très nouveau), mais Red Hat (ou Novell) n'est pas con au point de se faire pièger. NB : On parle d'entreprises commerciales !
L'objectif, si je le comprend bien, est respectable. Canonical veut Oracle, etc sur Ubuntu. Mais le moyen utilisé est n'importe quoi.
Il est méprisant pour le libre. Il est irréaliste (sauf dans un cas, j'y reviens). Faut vraiment prendre Red Hat et Novell pour des gogos pour y croire.
Ça allège aussi les coûts d'Ubuntu mais je crois que l'essentiel n'est pas là.
Il serait très bien d'avoir une troisième acteur GNU/Linux pour les entreprises. Mais pas comme le fait Ubuntu. L'insistance de Mark S. montre qu'il y a un vent de panique chez Canonical.
Ou, si ça marche, c'est que Novell est aussi dans la même panique que Canonical et que sa survie dépend d'un partenariat avec Canonical.
Pourquoi pas. Mais le discours pipo de Mark S. me chauffe les oreilles.
Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Je vois pas en quoi c'est foiré, la dernière Mandriva est basée sur cette collaboration entre Mandriva et TurboLinux, et TurboLinux est je crois sur le point de sortir une version de leur distrib sur cette meme base, donc ca se passe bien, et il ne me semble qu'il soit prevu d'arreter cette collaboration.
Tu ne sais meme ou ca en est, et pourtant tu affirmes que c'est foiré. Ah mais oui, j'oubliais, selon toi, tous les trucs dans lesquels n'intervient pas RedHat/Fedora sont forcement foirés :)
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.
Donc j'ai aucun avis si ça a réussi ou non.
En passant, si tu veux savoir ce que j'en pensais au moment de l'annonce, pour moi ça n'allait pas marcher.
Beaucoup se feront plaisir de me démontrer que j'avais tord.
Tu as en synthèse ce qui en est sorti sur http://blog.mandriva.com/2008/04/08/bits-and-pieces-about-th(...) La 2008.1 Spring inclut les travaux qui en sont sortis (sur gcc, kernel, rpm...), beaucoup de paquets ont maintenant une extension mnb1 et non plus mdv, comme ont pu le remarquer beaucoup d'utilisateurs de Mandriva Linux.
Donc oui, ça avance, il n'y a pas de communication particulière à faire pour l'instant à ce que j'en vois sur le net.
De toute façon, c'est surtout un travail de coordination, plus facile à faire entre 2 entités que dans un magma où Mandriva n'aurait pas forcément son mot à dire. L'important est qu'il y ait des choses de faites, les échos que j'en ai eu à Solutions Linux sont plutôt bons, les résultats se sont vus dans la Spring.
En aparté, tu sais, Mandriva est une société, elle communique comme elle veut et ne te doit pas de comptes ou d'explications, quand bien même elle bosse dans le libre : son meilleur livrable reste les logiciels libres produits et la distrib' qui profite à tous. Moi aussi à une époque j'aurais voulu plus de communication, puis en tant que simple utilisateur je suis devenu rationnel : cela ne me regarde pas forcément et ce n'est pas à moi d'exiger cela ;-)
Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
> bin tu sautes rapidement aux conclusions... sans élément factuel.
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Je n'ai jamais conclu que c'était un échec !
Où j'ai dit ça ? J'ai dit que je n'en savait rien ! J'ai dit que je n'en savait rien !
Où tu vois une conclusion ?
Maintenant, merci pour les informations que tu nous donnes. Elles indiquent que ma PRÉDICTION (et non conclusion) de l'échec de la collaboration entre Mandriva et TurboLinux était fausse.
> et ne te doit pas de comptes ou d'explications
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Merde, je peux dire des trucs sur des choses même si ces dernières n'ont pas de compte à me rendre.
J'ai jamais demandé à Mandriva où autre de rendre des comptes sur la collaboration entre Mandriva et TurboLinux.
Sûr que tu as critiqué MS-OOXML, pourtant MS-OOXML n'a pas de compte à te rendre (à moins que tu ais payé MS pour MS-OOXML...).
> Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
N'hésites surtout à nous tenir informé [1]. Tu peux dire que ma PRÉDICTION était fausse et te foutre de moi. Mais n'invente pas une conclusion que je n'aurais jamais faite.
[1] : Ceci ne te demande pas de me rendre des comptes, c'est seulement une invitation à nous tenir informer. Tu peux évidemment te torcher le cul de cette invitation.
Bin je vais te donner 2 lectures de ce que tu as écrit :
Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Cela peut se comprendre ainsi, en forçant le trait :
a) des tentatives ont foiré, par exemple celle de Mandriva et TurboLinux
b) il y a eu déjà des tentatives, par exemple celle de Mandriva (d'ailleurs où cela en est-il, cela porte-il ses fruits ?)
Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions, la réponse que tu me fais le démontre bien, tu vas même au plafond ;-) (un peu comme le double-jump aux dérivés libres de ioquake3)
Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé, mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Je ne te rendrai pas de comptes, mais je me renseignerai, ne t'inquiète pas, pour mon info (et je ne te dirai peut-être rien, na :p ou pas).
> Cela peut se comprendre ainsi, en forçant le trait :
J'ai admis qu'il y a avait peut-être (voire manifestement) une erreur de formulation.
J'ai clairement, il me semble, rectifié ce que je voulais dire.
Je m'excuse encore de m'être mal exprimé.
Par pitié, ne parlez pas de mauvaise fois, lorsque je veux dire quelque chose je le dis.
> Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
http://linuxfr.org/comments/931937,1.html
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.(*) Donc j'ai aucun avis si ça a réussi ou non.
(*) : c'était vrai au moment du post.
> tu peux l'assumer hein.
Très bien, j'assume avoir mal formulé, j'ai corrigé déjà une fois, je veux bien le refaire. J'ai aucun problème à reconnaitre mes erreurs. J'ai aussi beaucoup de respect pour ceux qui reconnaissent leur erreur il est donc normal que je reconnaisse les miennes.
Mais ce que je n'ai pas voulu dire, je n'ai pas voulu le dire. Point barre !
> tu peux l'assumer hein.
J'assume parfaitement ma mauvaise prédiction.
Si tu veux te foutre de moi car ma prédiction était fausse, fait le.
Je ne te critiquerai pas dans la "mamoeuvre", même si évidemment je n'apprécierai pas ça.
M'enfin, j'assume ma mauvaise prédiction.
Par contre, je ne m'excuserai pas sur ma mauvaise prédiction. Ce n'était qu'une prédiction.
> Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions,
Quelle conclusion ?
A toi d'assumer, puisque ça fait deux fois que tu parles de conclusion, où as-tu vu que je faisais une conclusion sur le deal Mandriva et TurboLinux ?
Assume : cherche et trouve !
Assume : si tu ne trouves pas, excuse toi.
> tu vas même au plafond ;-)
J'ai horreur qu'on me prête des propos que je n'ai pas tenu.
Je comprend bien qu'on puisse faire des erreurs (moi, toi, tout le monde).
Mais arrête de dire (comme encore un fois ici) que j'ai fait une conclusion sur le deal entre Mandriva et TurboLinux.
En passant, prêter des propos à une personne alors qu'elle ne les a pas tenu est de la diffamation. Ne t'inquiète pas, je ne vais pas t'attaquer en justice pour ça. Mais merde, c'est grave !
> Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque
J'ai déjà dit que je n'avais aucun élément. Merci (ça doit être la troisième fois que le dit...) d'avoir apporté des éléments.
Et alors ?
J'assume mon avis de l'époque.
Lorsque j'ai écrit "on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)", oui je m'attendais à ce que le deal entre Mandriva et TurboLinux ait foiré. Je m'y attendais. Ma pensée était aussi sur ma prédiction. Je n'ai aucun problème de le reconnaitre. Mais ce n'est pas une conclusion sur le deal entre Mandriva et TurboLinux (Diantre, il y avait où en est ce truc ?).
> tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé
Je vais te le dire tout net :
- je t'emmerde, je dis ce que je veux. Je n'attend pas ta demande, ni aucune demande.
> mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Tu fais très mal les conclusion des autres.
Juste en passant, quand Mandriva 2008.1 est sortie avec FF 2 (NB: Ubuntu 8.04 n'était pas sorti) il y eu des critiques pour dire que Mandriva aurait dû sorti avec FF 3.
J'ai dit que je trouvais normal que Mandriva 2008.1 utilise FF2.
Mais ça évident tu n'as remarqué. Tu fais une lecture sélective et après ne rate pas une occasion de chier une pendule.
J'ai dit plus d'une fois que je préfère l'époque post-Duval de Mandriva à l'époque Duval.
Mais ça encore une fois tu oublies.
J'ai dit que je m'attendais à voir un rebond de Mandriva car Mandriva fait, il me semble, globalement un bon boulot aujourd'hui.
Mais ça encore une fois tu oublies.
Si tu as la moindre information sur un regain de forme de Mandriva, donne les. N'hésite pas une seconde.
Si c'est l'inverse et que ma prédiction est fausse, donne les infos, fous toi de ma gueule.
Ce sont des informations sur des fais, elles sont toujours les bienvenues.
Pourtant, si j'étais aussi diabolique que tu veux le faire croire, pour justifier qu'on m'insulter de mauvaise fois, etc, pourquoi tu ne dis rien lorsque je dis quelque chose de positif sur Mandriva ?
Mais non rien. Ce qui est normal en fait. Mais ce qui n'est pas normal c'est de venir systématiquement me chercher des poux dans la tête.
Il y a eu "fiasco SSL" et certain disait "je vais passer à Fedora" d'autres disait "je vais passer à Mandriva". À ces derniers je n'ai pas dit "tant qu'à changer de distribution, passez à Fedora". Pourquoi diable je n'ai pas fait ça alors que je suis diabolique de mauvaise fois, et gnagnagna et gnagnagna ?
> J'ai dit que je m'attendais à voir un rebond de Mandriva
Oui, j'assume ma prédiction et la remet ici.
Je n'attend pas que mes prédictions soient confirmer pour "au moment opportun" dire "je vous l'avais dit".
"Strength is irrelevant. Resistance is futile. We wish to improve ourselves. We will add your biological and technological distinctiveness to our own. Your culture will adapt to service ours."
-- The Borg, Star Trek: The Next Generation episode "The Best of Both Worlds" (1990)
Ouep. Mais il me fait de la peine, il va voir que c'est un coup d'épée dans l'eau, et par fierté, s'enfoncer encore plus (c'est à dire dans son cas écrire encore plus d'entrées de blog style "personne m'écoute c'est de votre faute si Linux il est pas mieux >___<").
C'est marrant tout ce buzz introduit par notre "ami" Mark à propos des dates de releases .
Mais quand est-il des gens qui utilisent des distros dites "Rolling Release", comme Archlinux, Gentoo, Debian Unstable pour les plus connues et tant d'autres (Foresight, Sourcemage ...) ? Et bien tout simplement ils n'en ont rien à faire !
J'ai de plus en plus de mal avec ces distros qui nécessitent une mise à jour (jamais simples) tous les 6 mois !
Autant je comprend parfaitement RHEL, Suse LE et Debian stable. Compatibilité binaires, ABI, API etc .. OK !
Autant je ne comprend pas du tout Ubuntu Desktop ou Fedora ou Mandriva et leurs releases tous les 6 mois.
Pour les entreprises oui, pour les geeks/developpeurs non !
Qu'on ne me dise pas que les gens cherchent la stabilité! Ils passent leur temps à chercher des backports ou a ajouter des dépots pour tester la dernière beta de kde4 ou banshee1 ou autre !
En plus Ubuntu et Fedora délivrent des logiciels en version beta (gdm, Firefox entre autres). Et puis franchement qui n'a pas eu des problèmes avec des mise à jour pendant le cycle régulier d'Ubuntu ou autre ? Une "Rolling Release" distro telle qu'Archlinux ou Gentoo n'a rien à envier à personne en terme de stabilité !
- Avec une "Rolling Release" distro c'est rare, mais tu peux avoir des problèmes lors de mises à jours.
- Avec une "Cycle Release" distro c'est rare, mais tu peux avoir des problèmes lors des mises à jours pendant le cycle de vie d'une release, et EN PLUS tu te tapes tous les tracas d'une mise à jour de release !!!
Quelqu'un peut m'expliquer pourquoi certains aiment tant mettre à jour tous les 6 mois ? Quelqu'un peut m'expliquer ce qu'apporte une "Cycle Release" distro par rapport à une "Rolling Release" ?
Enfin et je terminerai là-dessus :
Je me balade beaucoup sur les bug tracker d' "Upstream", Gnome en particulier. C'est impressionnant le nombre de contributions de Fedora. C'est gens là font beaucoup avancer le libre et sont vraiment discrets (ça me plait). Tout ce que fait Ubuntu c'est "ce bug a aussi été reporté sur launchpad".
Notre "ami" Mark aiderait plus en passant plus de temps Upstream qu'en bloggant dans le vent.
Ben justement : les développeurs ont moins de boulot dans les "Rolling Release" distros, paradoxalement.
Quand je regarde Arch et la taille de la communauté des devs, je suis impressionnés par le boulot fait !
Et aussi le plus les paquets sont Vanilla (non patchés) le moins tu as de boulot. Avec un bon gestionnaire de paquets, changer la version dans un fichier suffit la plus part du temps. Fedora l'a bien compris et c'est une des raisons (pas la plus grande) pour lesquels ils poussent tout upstream.
Mais je dérive vers une autre discussion : paquets patchés ou pas ? Je devrais aller poster dans le thread sur la faille SSL ...
> Ben justement : les développeurs ont moins de boulot dans les "Rolling Release" distros, paradoxalement.
Ce n'est pas ça le plus important.
Avec une release (et donc la phase de développement de celle-ci) tu peux te permettre de tout casser. Tu peux changer de compilateur (ce que fait encore une fois Fedora avec F9), etc.
Il y a une grande liberté et donc aussi une grande efficacité pour le développement (on ne se contente pas de packager, on va plus loins).
Enfin les mises à jours de distribution n à n+1 avec Fedora sont fait hors du système qui va être mise à jour. Tu peux alors passer de ext3 à ext4, changer le format rpm, changer init, etc. Il y a une grande liberté de développement.
Les développeurs Fedora ont une Fedora stable pour le boulot de tout les jours (une F8 ou F9 typiquement). Et ils ont aussi une Rawhide (la branche de développement) pour coder/tester/etc. Si la branche de développement explose, ce n'est pas grave (c'est même courrant et c'est aussi ce qui fait le charme de Fedora pour beaucoup de contributeurs).
> Avec une release (et donc la phase de développement de celle-ci) tu peux te permettre de tout casser
Avec une Rolling aussi : il y a un dépot "testing" ou les devs font tout le boulot. En particulier quand un nouveau GCC sort il est testé localement par le développeur, puis mis dans testing pour que tous les développeurs (et utilisateurs du dépot) puissent tester. Si une recompilation du dépot est nécessaire alors c'est fait.
Quand un logiciel est jugé stable il monte dans la branche 'stable' et tout le monde en profite.
Certains logiciels montent plus vite que d'autres tu imagines bien.
> Il y a une grande liberté et donc aussi une grande efficacité pour le développement (on ne se contente pas de packager, on va plus loins)
Loin de moi de contester la qualité du travaille de Fedora. Je viens souvent leur piquer des idées. Mais je ne vois pas en quoi le fait qu'il y ait des releases améliore la qualité d'un paquet : tu bosses sur une version, tu apportes (ou pas) ta valeur ajoutée, tu tests et tu délivre le paquet ! Il y a besoin d'une release pour ça ? Un repo de testing c'est pas suffisant ?
Je ne vois pas le rapport entre qualité, valeur ajoutée et release/rolling release ?!
> Quand un logiciel est jugé stable il monte dans la branche 'stable' et tout le monde en profite.
Ce n'est pas pareil.
Avec Fedora, du jours au lendemain (ou presque) tous les paquets sont compilés avec gcc 4.3.
Il y a un release manager (ou un truc dans ce goût) pour tout coordonner. Ce n'est pas qu'un "bac sable".
> Mais je ne vois pas en quoi le fait qu'il y ait des releases améliore la qualité d'un paquet
Je ne parle pas de qualité, mais de développement.
Ces aspects ne sont pas forcément liés.
> tu bosses sur une version, tu apportes (ou pas) ta valeur ajoutée, tu tests et tu délivre le paquet !
Ben justement, Fedora ne fait pas que ça.
Fedora prends des trucs en CVS, bosse sur Rawhide, contribue upstream, etc.
Et tu as bien remarqué que Fedora contribue beaucoup en upstream. Fedora ce n'est pas et ça ne veut pas être seulement packager des logiciels.
> Il y a besoin d'une release pour ça ? Un repo de testing c'est pas suffisant ?
Fedora a aussi son dépôt testing...
Mais ce n'est pas suffisant.
Si t'es très content avec arch, et je n'en doute pas, pas de problème, éclate toi.
OK, ça n'a aucun intérêt, Fedora fait ça pour le fun (NB: Fedora ne vend rien, il n'y a pas de calendrier commercial).
Disons que Fedora est maso et aime ça.
J'aime ça aussi.
> Bref je n'ai toujours pas vu d'arguments convainquant pour un système de releases tout les 6 mois ?
Il y en a aucun.
Mais bizarrement les distributions les évoluées utilise les releases tous les 6 mois.
Mais c'est seulement le hazard.
Non, je voulais plutôt dire qu'il y a aussi debian, gentoo, etc ... et que je trouve que ce sont des distributions tout aussi "évoluées" qu'opensuse ou ubuntu.
Elles ont juste des buts et des points forts différents.
> Ah, bah alors le problème est peut-être que je ne comprend pas ce que tu entend par distribution "évoluée"
Très bonne remarque.
Ma notion d'évoluée n'est peut-être pas la tienne et je ne prétend pas que la mienne soit forcément plus pertinente qu'une autre.
> Est-ce que tu pourrais m'en dire plus ?
Si c'est pour partir sur un débat sur ce qui est évolué ou non, je préfère éviter. Ça va être une interminable "bagarre" et rien que de l'envisager ça me fatigue :-)
Il y en a aucun.
Mais bizarrement les distributions les évoluées utilise les releases tous les 6 mois.
Mais c'est seulement le hazard.
Oui, et windows a plus de 90% de parts de marché, et si 75% des gens bouffaient de la merde, je me dirai que la merde, ça doit être vachement bon.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Je suis sous Mandriva 2008.1, et tout marche bien. Pourquoi aurais-je besoin de mises-à-jour constantes sur tout mon système ? Exemple : pourquoi changer de version de noyau si mon système tourne très bien comme ça ? Pourquoi changer de libc si ça marche ?
- Tu peux très bien avoir ce mode de fonctionnement avec une Rolling Release. C'est toi qui choisit quand tu update et ce que tu update (failles de sécurité entre autres). Certains font des updates tous les jours, d'autres tous les mois, et d'autres tous les ans !
Si tu n'as pas fait d' update depuis très longtemps et que tu veux updater juste un paquet, peut-être auras tu besoin de le recompiler pour qu'il passe avec ta toolchain ... Ce qui est fait automatiquement sous Gentoo et très facilement sous Arch. Tu disposes aussi de paquets avec les vielles versions de softs libs en particulier gcc3 si tu veux ...
En ce qui me concerne j'update tous les jours, mais j'ai une blacklist de paquets critiques pour moi à ne pas updater (pacman permet ce genre de fonctionalité comme beaucoup d'autres d'ailleur).
- J'ai le sentiment que ce type de comportement ne concerne qu'une petite partie de gens sérieux comme toi et que beaucoup d'utilisateurs d'Ubuntu cherchent surtout la nouveauté : j'en veux pour preuve le buzz assourdissant à chaque sortie de ce type de distro.
Enfin je te retourne la question : tu feras comment quand Mandriva ne supportera plus les mises à jour de ta version ?
Hello Chicha, ça va ?
En fait, ne mettre à jour que tous les 6 mois me convient de plus en plus. Généralement, j'ai fait tellement de conneries sur ma machine à installer des softs dont je me fous que je préfère repartir de 0. Je crois que j'étais friands des nouveaux softs à l'époque où il y avait vraiment de l'innovation et en ce moment, c'est franchement le vide complet.
Arch et Gentoo permettent effectivement d'être fin et en ce sens sont très intéressantes. Par contre, j'aurais bien aimé en plus une approche à la BSD où une distinction claire est faite entre système et logiciels autour. C'est évidemment possible sous Gentoo, mais ça demande plus de travail.
Il y a vraiment une chose qui m'empêche d'être sous FreeBSD c'est le support Hardware plus restreint que sous Linux. J'ai malheureusement une carte Wifi exotique tout juste supportée sous Linux et qui ne fonctionne pas avec la dernière version de FreeBSD. Je l'ai bien cherché aussi : j'ai acheté ma carte à la fnac sans regarder !
Ceci dit Arch et Gentoo sont très proche des BSD dans l'esprit.
Quand à l'innovation actuelle dans le monde Opensource je ne sais pas trop quoi en penser. Avec toutes la com' (blogs, news, ...) je suis un peu perdu. Mais quand j'utilise un Windows ou un Mac j'ai le sentiment que les logiciels libres ont pris un ascendant techniques net. Peut-être que je m'emballe ...
Tiens encore quelqu'un qui pense en binaire.
Sachez, qu'entre les "cycle release" et les "rolling release", il y a les vraies distros qui savent faire la part des choses (aka base stable + dernières versions des applications tierces) comme Gniarf Linux, Lapwing Linux et Draco Gnu/Linux (je ne compte pas Gentoo qui est une distribution source, PC Linux OS qui n'écrit pas clairement son modèle de développement sur sa page d'accueil, ni foresight Linux idem que PCLinuxOS).
Un autre commentaire intéressant, par Pascal Bleser (yaloki), l'un des contributeur externe d'openSUSE les plus actifs et membre de la board openSUSE également.
Pour moi ce sujet de synchronisation est important mais pas pour le proprio (enfin ce n'est pas l'aspect qui m'intéresse le plus, à eux d'essayer de suivre, pas au libre de s'adapter) ; la synchro est intéressante pour éviter de rater les échéances et courir derrière le noyau (notamment le noyau, mais il y a aussi côté applications).
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
Tu parles de l'openSuSE build service ? http://en.opensuse.org/Build_Service
C'est effectivement très pratique, pour les projets voulant offrir des paquets pour diverses distributions ou tester la compilation sur une autre architecture.
Sinon, FedoraProject a sa propre ferme de compilation, actuellement Koji
autrefois Plague. FedoraProject est recompilé dans sa totalité à plusieurs reprise lors du cycle de développement, avec l'envoi d'un mail au mainteneur si la compilation automatique échoue.
Koji offre également la possibilité de créer des dépôts personnels mais cela n'est pas activé par défaut. L'outil est capable de compiler des paquets pour n'importe quel distribution utilisant RPM, il suffit de créer un fichier de configuration pour le chroot de compilation (Mock).
> Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms
FedoraProject n'utilise pas dkms pour diverses raisons.
Les modules noyaux (kmod) sont générés à l'aide de l'outil kmodtool, et il existe également des akmod pour simuler un comportement à la dkms. Tu as un service akmod qui au démarrage, teste l'existence d'un module précompilé et qui si nécessaire recompile le src.rpm.
Oui, je parle du build service.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel
> J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Tu peux sourcer ?
Donne des cas précis.
Parce qu'en fait, j'ai l'impression que tu n'as pas d'argument pour critiquer le processus (ou l'organisation). Tu es seulement déçu. Je veux bien l'entendre, mais ce n'est pas à mon avis suffisant pour remettre en cause le processus et son application.
Puis tu sembles totalement faire l'impasse sur les distributions qui ne montent pas en version de noyau et font des backports (RHEL, SLES, etc les distributions "entreprise"). Pour ces dernières, ça marche exactement comme le dit Andrew Morton.
> Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
Dans ce domaine, la distribution Fedora fait une grosse contribution (les noyaux ont toujours les derniers patchs wifi ; normal c'est un employé Red Hat qui maintient wifi).
> - les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
Et ?
La priorité de l'upstream est mise sur ce qui va marcher, pas sur ce qui ne marchera jamais bien. Ça me semble très normal.
> - Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
C'est le boulot de Mandriva (vu sa cible). Ce n'est pas le boulot d'autres distributions.
Tu as peut-être mal compris Andrew Morton. Il n'a pas dit que les distributions on tobligation de faire ce que fait Mandriva. Il a voulu dire que l'upstream sera plus concentré sur le développement que de fournir un noyau directement utilisable par les distributions. Les distributions doivent donc s'attendre à fournir du boulot et non seulement piquer le noyau sur http://www.kernel.org/ . Une distribution peu bloquer la sortie d'une nouvelle version s'il y a un driver très utilisé qui sucks. Le noyau vanilla ne le fera pas (ou beaucoup moins).
> Tout l'intérêt de dkms est de "gentoo-ifier" les modules
Ce n'est pas toujours vraiment intéressant (or pour voir si la recompilation marche).
Fedora a un système pour "récupérer" les modules de l'ancien noyau qui ne sont pas dans le nouveau lors de la mise à jours. Ceci est fait si l'API utiliser par le module n'a pas changée.
On retrouve ses modules dans /lib/modules/`uname -r `/weak-updates après la mise à jour.
NB: pour Fedora dkms n'est pas très intéressant puisque Fedora a souvent la dernier version du noyau. Donc si le système "weak-updates" ne marche pas, il faut très probablement des nouveaux sources pour le module et donc repackager le module (pas seulement le recompiler).
Je crains que les choses sont plus compliquées.
Il y a les distributions communautaires qui veulent être très proche de l'upstream (Fedora, Gentoo, etc). Les mi-communautaire / mi-commerciale qui mette leur plus value à une version du noyau (pilote avec ancienne pile wifi, etc) pour la satisfaction de leurs clients. Ces dernières ont une mission "produit" plus marquée.
Il y a les distributions presque exclusivement commerciale : RHEL, SLES, etc.
De quoi tu parles ? :-)
De quoi tu parles ? :-)
comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva et par rapport à mon titre de ceux qui "suivent" et non qui avancent à la même cadence que l'upstream : cela concerne les distribs' stables (donc peut concerner Fedora 7, Fedora 8, maintenant Fedora 9 mais pas rawhide).
Fedora 8 en est au 2.6.23.1 d'après distrowatch. Dans cette branche Andrew Morton en est au 2.6.23.17, non pris en compte tel quel (si j'en crois distrowatch). Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Sur Mandriva Linux 2008.1, il y a le 2.6.24.4, Andrew en est au 2.6.24.7 et je ne crois pas qu'il sera pris en compte, cela passera par des backports au mieux ou sinon il y a le kernel-linus-2.6.25-0.rc6.1mdv (principalement upstream).
packages.ubuntu.com est down, je n'ai pas vérifié mais je ne pense pas qu'ils soient à la dernière version non plus.
Je ne remets pas en cause, je constate simplement des difficultés rencontrées par les distributions à accrocher au processus : cela sert pour le choix initial du kernel, ensuite chaque distrib' a sa politique de mise à jour et de constitution de "son" kernel (backports, dkms). Mandriva va aussi chercher des pilotes qui n'ont pas encore fait l'effort d'être inclus dans le kernel (il y a aussi de l'upstream du kernel hein ;-) ).
Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
Pour les dkms, je notais simplement un moyen supplémentaire de mettre à jour par morceau le kernel plutôt que d'attendre qu'un nouveau kernel soit packagé. Ayant bossé sur l'upstream de module, c'est intéressant quand ton code n'a pas encore été poussé dans le kernel et qu'une distrib' s'y intéresse (le paquet dkms permet de constituer le backport directement pour une floppée de versions de kernels, même si ce n'était pas l'utilisation initiale prévue pour dkms).
> comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva
OK, désolé.
Mais ça ne reste toujours pas claire.
Que pointes-tu ?
Un manque de moyen ?
Des conflits dans les rôles ?
Je comprend mal.
> Fedora 8 en est au 2.6.23.1 d'après distrowatch.
Distrowatch est une bonne source d'info. Mais pas toujours exacte.
Actuellement pour F8 c'est un 2.6.24.7 (mise à jour du 14/05).
Je ne sais pas si un 2.6.25 est prévu. Mais il ne faudra pas être surpris s'il y en a un. S'il n'y a pas encore de 2.6.25, j'image que c'est à cause d'un manque de moyen (ou d'autres priorités, ou une meilleure opportunité qui se présentera un peu plus tard, etc).
> Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
> Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
C'est /sbin/weak-modules (un script sh) qui le fait (appelé par les scripts d'installation du rpm kernel). /sbin/weak-modules est dans module-init-tools.
Mais, tel est Fedora, bourré de surprise :-)
L'appel à weak-modules est mis en commentaire depuis peu de temps .
J'ignore précisément les raisons.
Je n'ai trouvé que ça comme info : http://www.redhat.com/archives/rhl-devel-list/2007-March/msg(...)
FWIW, weak-modules will go away in a future Fedora. The plan is to replace it with a much more comprehensive online driver update tool that will do a lot more than just create symlinks - more information when I have an example to share... :-)
En passant, je veux aussi dire que je ne suis pas contre la coopération entre les distributions.
Bien évidemment.
Mais un "état major" qui fixe ce qu'un ensemble de distribution de faire : c'est non.
https://lists.ubuntu.com/archives/sounder/2006-January/00363(...)
4. The Premise. The vision behind DCC, which is indeed compelling, is that it would provide a common platform for certification, and that the distros that make up the DCC would all ship exactly that same core. But it strikes me that this approach has never worked in the past. In fact, every distro ALWAYS modifies elements of the core, and with good reason. And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity. Much as it may be compelling, the common core idea is ultimately flawed, because it's not just the bits at the core that matter. An ISV that certifies an OS is not just certifying the pieces on which it's app depends. It's also certifying the *environment* which it will support, which includes installer, documentation, even packaging. Screenshots, for example, won't be useful unless they reflect all of the certified OS's, and that's not possible in the DCC model. There have been several examples of places where this idea has failed. United Linux is one.
Joli retournement de veste Monsieur Mark Shuttleworth.
# osef
Posté par libre Cuauhtémoc . Évalué à 7.
# Une question
Posté par Dr BG . Évalué à 7.
[^] # Re: Une question
Posté par GCN (site web personnel) . Évalué à 1.
[^] # Re: Une question
Posté par Dr BG . Évalué à 4.
- il parle de fedora
- il poste deux commentaires à la suite (comme IsNotGood le fait souvent sur linuxfr)
- le journal ce blog et IsNotGood à des réactions très vives sur le sujet donc autant en mettre en commentaire sur le blog
- c'est de l'anglais qui est typiquement écrit par un français :-) (ex : I am not agree)
Enfin bref, je pose cette question simplement parce que je suis curieux de savoir si mon intuition est bonne et j'aimerais bien savoir si je suis un excellent détective.
[^] # Re: Une question
Posté par Dr BG . Évalué à 2.
Aïe, c'est mal de modifier une phrase sans la relire entièrement ensuite. Je recommence : "le journal pointe ce blog, et IsNotGood..."
[^] # Re: Une question
Posté par IsNotGood . Évalué à 4.
Ça change rien. Sauf qu'on sait maintenant, preuve à l'appui, que mon anglais est moyen :-)
[^] # Re: Une question
Posté par Dr BG . Évalué à 5.
En effet, ça ne change rien. Simple curiosité !
# La réponse d'Aaron Seigo
Posté par GeneralZod . Évalué à 6.
Ce billet est une réponse au billet d'Aaron Seigo (LE guru KDE) qui explique pourquoi l'idée de Mark S. est stupide
-----------------------------------------------------------------------------------
On pouvait considérer le premier billet comme une intervention maladroite voire naïve mais là, il s'enfonce, c'est même dangereux ce qu'il propose.
The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.
Si toutes les distributions collaboraient un peu plus en upstream, ce serait inutile.
Si on doit partager des informations, des patchs et des rapports de bogues, ça doit être fait au niveau de l'upstream et uniquement à ce niveau-là.
ça n'empêche pas aux distributions d'avoir un espace d'échange pour partager leurs expérience au niveau du packaging, de l'intégration mais ça ne doit pas faire doublon avec l'upstream.
Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true.
On y croit vachement.
I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world.
FOUTAISES ! Le but du logiciel libre est de fournir une alternative au logiciel propriétaire pas de l'affronter. ça c'est l'objectif des boites commerciales autour du libre que ce soit Canonical, RedHat, Novell etc... Les boites et le logiciel ont des intérêts communs mais nos objectifs ne sont pas les mêmes.
we’re more likely to have the same versions of key components at any given time.
C'est exactement ce qui lui a été proposé dans Debian Common Core et c'est exactement ce qu'il a refusé.
these are items which likely need the most stabilisation and testing before they ship to the innocent
C'est un travail de tout les jours, ce n'est pas en focalisant sur une version précise qu'on améliorera la situation. Pour cela, il n'y a pas de secret, il faut travailler en UPSTREAM.
I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!
On voudrait des noms, parce qu'à part les éventuels développeurs noyaux employés par Canonical j'y crois pas un instant.
Si il est capable de citer les personnes qui ne sont pas d'accord avec lui, il peut très bien faire l'inverse.
we would be able to improve greatly ALL of their support for today’s hardware
C'est le truc qui m'a le plus énervé. En gros, son but est de stabiliser les gros composants des principales distributions pour faciliter le support des pilotes propriétaires.
Alors que la communauté du logiciel libre se bat pour la libération des specs et des pilotes, Mark Shuttleworth lui enfonce un poignard dans le dos.
Et après, il ose dire qu'il soutient le logiciel libre ? Autant ce discours est compréhensible dans la bouche d'un chef d'entreprise, autant c'est inadmissible de la part d'un libriste.
Favoriser les pilotes propriétaires ne feront pas et ne feront jamais avancer le logiciel libre, ça peut favoriser les affaires d'une boite commerciale à un moment donné mais basta.
Mark S. nous propose un modèle propriétaire, seuls les composants sélectionné par les "boites" auront un support matériel correct, les autres devront marcher au pas.
Les constructeurs ne supporteront que les composants sélectionnés (les autres iront se faire foutre), les constructeurs n'auront pas envie de changer de politique vis à vis des pilotes libres (après tout, ça marcherait bien comme ça) ça reviendrait à faire un doigt aux autres plateformes libres (*BSD & cie), ils n'ont qu'à utiliser Linousque LTS (la fusion entre Ubuntu LTS, RHEL, etc ...)
Le pire c'est qu'il prévoit d'étendre ça à d'autres composants, c'est à dire à plus moins long terme, la sclérose de GNU/Linux, Il ne faudra plus casser les pilotes et logiciels propriétaires, bref, on finira comme Windows, une plateforme fade et sans innovation, trainant de gros boulets.
[^] # Re: La réponse d'Aaron Seigo
Posté par Spyhawk . Évalué à 4.
Comme Ubuntu ?
(ah ouai, upstart... ooops ---> [])
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . Évalué à 5.
Mais ce qui arriverait, si les distributions majeures acceptaient cette proposition de figer les composants majeurs. Aujourd'hui, le nombre de pilotes propriétaire dans Linux est relativement restreint mais si on leur facilite la tâche, ils se multiplieront et on finira par ne plus pouvoir s'en passer. Et quand on sera tributaire des pilotes propriétaires, on sera poings et pieds liés.
On ne pourra plus corriger le noyau ou X ou du moins proprement si on a le malheur de casser un pilote.
Hein, il parle dans un second temps d'étendre ce concept au bureau, vous imaginez le jour ou il faudra faire de gros hacks pour ne pas casser MS Office Linux Edition parce que MS ne prévoit pas de mises à jour avant 3 ans.
[^] # Re: La réponse d'Aaron Seigo
Posté par SF . Évalué à 3.
Si toutes les distribs passent de la version x à la version x+1 d'un composant en même temps, tu facilites la vie des développeurs de pilotes propriétaires car ils n'ont qu'une seule cible à atteindre mais d'un autre coté rien ne t'oblige à conserver la compatibilité pour autant, ça s'est le problème de l'upstream. Et j'imagine assez mal Fedora acceptant de ne pas passer à la version x+1 sous prétexte qu'nvidia n'est pas prêt. Et là je pense que l'on touche du doigt le problème de l'idée de Mark Shuttleworth : comment seront décidé les versions utilisées par tous ?
Ceci dit je pense que la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre. Et s'interdire un truc juste parce que le logiciel propriétaire en profiterait... ça me fait un peu trop penser aux bugs windows présents en apparence juste pour emmerder la concurrence.
Personnellement j'aime bien que les différentes distributions aient des versions différentes, fassent des choix différents. Ce qui m'inquiète le plus dans la solution proposée par le cowboy de l'espace c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . Évalué à 6.
Tu te trompes à ce sujet. Si tu décides que les distributions majeures utiliseront le même noyau, le même X, le même GCC, les constructeurs se borneront à supporter ces versions et point barre.
Si tu cales ton cycle de développement sur celui des pilotes/logiciels propriétaire, tu es foutu. Si un constructeur refuse de supporter tel ou tel version du noyau ou de Xserver, tu fais quoi? selon Mark S., soit je fige mon interface pour lui faire plaisir, soit je fous des gros hacks pourris pour contourner ça.
C'est ce que faisait XGL ou Beryl avec les pilotes propriétaires, au fur et à mesure des hacks, la situation est devenu inmaintenable.
Au final, c'est AIGLX qui a gagné parce qu'ils ont préféré faire les choses proprement et qu'ils ont obligé les constructeurs à adapter leurs pilotes. Idem pour Beryl qui a disparu au profit de Compiz.
La synchronisation n'est pas une mauvaise chose, mais il faut des objectifs communs, c'est ce que fait Eclipse, Freedesktop.org.
Mais ça ne peut pas marcher entre des distributions ayant des objectifs différents, avec un calendrier rigide sur 2 ans alors que la plupart des logiciels libres n'ont pas une vision claire de ce que sera leur avenir au-delà de 6mois/1 an.
ça ne peut par marcher, si on joue dans un rapport de force entre distributions/upstream.
Si il doit avoir synchronisation, elle doit se faire en upstream et pas ailleurs.
> la facilité offerte aux développeurs de solutions propriétaires serait également offerte aux développeurs du libre.
Justement, le logiciel libre n'a pas besoin de cette facilité. Quand on casse une interface dans le noyau ou dans X, les pilotes sont quasi automatiquement corrigés que ce soit par le mainteneur du pilote, du changement d'API, ou un tiers.
G. K-H explique très bien pourquoi une API interne stable dans Linux n'a pas de sens et n'est pas souhaitable.
C'est même un argument majeur pour libérer les pilotes, les boites propriétaires n'ont guère le choix, soit elles fournissent un effort supplémentaire pour suivre les développements, soit elles libérent les informations. Sur le long terme, seule la seconde solution est viable.
Ce que tu appelles difficulté est en fait une force du libre, à tout moment, si un composant n'est pas satisfaisant, je peux le remplacer sans avoir à me retenir.
Si tu prends Gnome-vfs, c'était une merde en pourriture, plus personne n'osait y toucher. En moins de 6 mois, on a pu écrire un remplaçant gvfs -avec une meilleure architecture- et modifier tout gnome afin d'utiliser celui-ci.
Aurait-il été de possible de faire de même si on devait se soucier de la compatibilité ? si on ne pouvait pas modifier le code librement ?
> c'est une perte de ces différences qui seraient préjudiciables aux projets qui seraient délaissés par toutes les distributions participant.
Si on poussait la logique jusqu'au bout, effectivement, on aurait une espèce de méta-distribution avec des différences mineures.
C'était envisageable dans le cadre des distributions dérivées de Debian mais ça ne l'est pas au niveau des distributions GNU/Linux.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 3.
Et surtout ils ne bosseront pas sur la version upstream, ils ne participerons pas au projet en upstream.
> Ce que tu appelles difficulté est en fait une force du libre
C'est clair.
Il y a une chose intéressante. RHEL/SLES amène le libre (tel qu'il est, tel qu'il a évolué librement) aux sociétés commerciales dont beaucoup font du proprio. Mais elles n'imposent pas le monde commercial/proprio au libre.
[^] # Re: La réponse d'Aaron Seigo
Posté par bubar🦥 (Mastodon) . Évalué à 2.
on peux pas "plusser" plus d' une fois à la fois
;)
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 3.
C'est aussi plus d'opportunité. Après tout, c'est bien comme ça qu'est né Ubuntu :-)
Un fork de Debian.
[^] # Re: La réponse d'Aaron Seigo
Posté par Okki (site web personnel, Mastodon) . Évalué à 2.
Dans cette dernière version, gvfs a remplacé gnome-vfs, mais cette bibliothèque sera toujours présente, justement pour assurer la compatibilité. Puis au sein d'une même bibliothèque toujours en place, telle que Gtk+, même si de nouvelles fonctions font leur apparition et que d'autres deviennent obsolètes, elles seront toujours présentes pour assurer la compatibilité.
Il n'y a que lors d'un changement majeur de version, tel que ce fut le cas de Gnome 1.x vers 2.x, et peut être un jour 3.x, qu'on peut se permettre de faire le grand ménage et casser la compatibilité. J'imagine qu'il en va de même pour d'autres composants majeurs du système.
[^] # Re: La réponse d'Aaron Seigo
Posté par GeneralZod . Évalué à 2.
Même dans GNOME, certains modules ne sont pas garantis comme étant stable au niveau de l'API ou de l'ABI, par exemple GStreamer.
Dans la mesure du possible, on évite de tout casser mais parfois tu n'as pas le choix.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
Très juste.
C'est seulement la gestion de la compatibilité.
Ce n'est pas fixer la date de sorti de gvfs et ses fonctionnalités pour une distribution commerciale.
C'est une différence énorme.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
>
> On y croit vachement.
Biensûr qu'on n'y croit pas deux secondes.
L'un des problèmes est aussi le mépris des forces en présence. Ce n'est pas "force" que dans le sens "celui qui a les plus grosses parts de marché où celui qui rapporte le plus pognon".
Si on prend l'aspect pognon, RHEL (et aussi SLES) gagne haut la main. Mais ses dernières ne vont pas imposer leurs calendriers/désires aux projets upstream ni aux autres distributions.
Pourtant Red Hat ne doit pas manquer de communiquants de talent pour enrober des fadaises du style : "synchronisez vous sur nous (ou 2 ou 3 distributions pour que l'intention soit moins criante), c'est bon pour le logiciel libre".
Red Hat ne le dira surtout pas car :
- RHEL répond à des exigences commericiales (pas aux exigences du libre)
- RHEL "se fout du libre", elle répond aux besoins des clients Red Hat, pas du libre.
Ubuntu est comme RHEL dans une certaine mesure.
Évidemment, Red Hat sera ouvert aux participations externes, accèpte très bien que le libre profite de RHEL (CentOS, etc), voire en est heureux. RHEL est aussi une distribution libre (mais commerciale) et Red Hat a toujours eu un comportement presque exemplaire avec le libre.
La "force" de RHEL pour le développement du libre est quasi nulle. Sauf le pognon que ça génère qui est ensuite en parti mis dans Fedora, développeurs upstream, etc. Mais c'est indirect.
Red Hat pourrait faire le coup de Mark S. avec Fedora. La force de Fedora est le développement et surtout le développement en bonne entente avec les développeurs upstreams. En bonne entente et non dans un rapport de force.
Debian pourrait aussi le faire, mais on touche à des problèmes quasi culturels et d'organisation. M'enfin, de par sa nature non commerciale, Debian est bien placé.
Mais même pour Fedora c'est malvenu. Fedora est aussi la base d'un produit commercial.
L'aide qu'a Fedora de la communauté, des développeurs upstream, Fedora la tient de ses participations au libre. Pas d'un calendrier commercial, pas d'un discours bisounours "c'est bon pour le libre". Fedora se met au service du libre (dans une certaine mesure évidemment mais une bonne et belle mesure). Via l'infrastructure (qui est libre dans le cas Fedora :-)), via des développeurs, etc. Pas l'inverse, le libre n'est pas au service de Fedora. Puis Fedora en tire profit car Fedora fait parti du libre et est dans la logique du libre.
Qu'es-ce qui "dicte" le calendrier de Fedora et ses fonctionnalités ?
Sa communauté qui veut une distribution vivante (donc qui sort souvent, avec le dernier cri du libre), ses objectifs (le développement du libre, rien à foutre si le driver proprio bidule explose), les développements upstream et la participation de Red Hat évidemment. Ce ne sont pas des besoins commerciaux (ou très accessoirement puisque Fedora est la base de RHEL).
On peut dire évidemment grosso-modo la même chose pour OpenSuSE.
On peut aussi le dire pour Ubuntu et Mandriva. Mais nettement moins.
Ce n'est pas une critique de Mandriva. Mandriva assume (aussi bien son choix d'être une distribution (partiellement) commerciale que son faible poid et ne joue le rôle de "nouveau leader du libre"). Si on veut un calendrier commercial, être driver proprio friendly, on assure. On ne demande pas gratuitement la coopération du libre pour vous aider à gagner du pognon.
Évidemment, tout ceci ne dit pas que la coopération est mauvaise. Si KDE aligne son calendrier sur Gnome, ça peut peut-être sympa, etc. Mais assurement, la demande ne doit pas venir de Canonical qui est clairement ici motivé par des enjeux commerciaux.
Donc, où veut en venir Mark S. avec cette magouille. Je fais ici une simple supposition.
Mark S. veut :
1) soit créer à une masse critique (Ubuntu + Debian + ....)
2) soit appartenir à une masse critique (RHEL ou SLES)
Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Pour le 2), ben il y a déjà CentOS, Oracle Linux, etc.
Le but est d'avoir, par exemple, Oracle supporté sur Ubuntu. Il n'y a pas de honte à ça. La méthode employée est par contre très très discutable pour ne pas dire pire.
Je vais parler que d'Oracle et RHEL, mais on peut généraliser.
Si Ubuntu est quasi la même chose que RHEL, Ubuntu va dire à Oracle : "on est populaire, vous avez fait tout le boulot pour RHEL, c'est trois fois rien pour vous de supporter Ubuntu".
Ubuntu pourrait faire une sorte de clone de RHEL (un clone pas aussi parfait que CentOS ou Oracle Linux). Mais les acheteurs ne sont pas dupes, ils savent que l'expertise est chez Red Hat et donc il achète du support Red Hat (du support c'est de l'expertise). L'échec d'Oracle Linux en dit long.
Cette voix doit être abandonnée. Ubuntu tente donc de diluer l'expertise de Red Hat. Ubuntu n'est plus alors une repompe de RHEL, mais Ubuntu et Red Hat des acteurs du noyau d'une distribution utilisée par Red Hat et Ubuntu (et d'autres).
C'est malin (quoique pas très nouveau), mais Red Hat (ou Novell) n'est pas con au point de se faire pièger. NB : On parle d'entreprises commerciales !
L'objectif, si je le comprend bien, est respectable. Canonical veut Oracle, etc sur Ubuntu. Mais le moyen utilisé est n'importe quoi.
Il est méprisant pour le libre. Il est irréaliste (sauf dans un cas, j'y reviens). Faut vraiment prendre Red Hat et Novell pour des gogos pour y croire.
Ça allège aussi les coûts d'Ubuntu mais je crois que l'essentiel n'est pas là.
Il serait très bien d'avoir une troisième acteur GNU/Linux pour les entreprises. Mais pas comme le fait Ubuntu. L'insistance de Mark S. montre qu'il y a un vent de panique chez Canonical.
Ou, si ça marche, c'est que Novell est aussi dans la même panique que Canonical et que sa survie dépend d'un partenariat avec Canonical.
Pourquoi pas. Mais le discours pipo de Mark S. me chauffe les oreilles.
[^] # Re: La réponse d'Aaron Seigo
Posté par Anonyme . Évalué à 2.
Je vois pas en quoi c'est foiré, la dernière Mandriva est basée sur cette collaboration entre Mandriva et TurboLinux, et TurboLinux est je crois sur le point de sortir une version de leur distrib sur cette meme base, donc ca se passe bien, et il ne me semble qu'il soit prevu d'arreter cette collaboration.
Tu ne sais meme ou ca en est, et pourtant tu affirmes que c'est foiré. Ah mais oui, j'oubliais, selon toi, tous les trucs dans lesquels n'intervient pas RedHat/Fedora sont forcement foirés :)
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 1.
Je n'es pas affirmé.
J'ai dit :
- "on a déjà vue des tentatives qui ont bien foiré"
Je n'ai pas dit :
- "TOUTES les tentatives ont foiré".
J'ai aussi ajouté avec un point d'intérogation :
- "Mandriva avec TurboLinux (où en est ce truc ?)"
[^] # Re: La réponse d'Aaron Seigo
Posté par Anonyme . Évalué à 3.
Quand tu dis "La dernière" il me semble logique de comprendre que tu parles de "tentatives qui ont bien foiré" et pas juste de tentatives.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.
Donc j'ai aucun avis si ça a réussi ou non.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 1.
Beaucoup se feront plaisir de me démontrer que j'avais tord.
[^] # Re: La réponse d'Aaron Seigo
Posté par Anonyme . Évalué à 4.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
Chaqu'un ses faiblesses...
[^] # Re: La réponse d'Aaron Seigo
Posté par BAud (site web personnel) . Évalué à 3.
Les travaux ont été annoncés en Janvier 2008 avec le manbo-labs,
blino en avait parlé sur http://blino.org/blog/mandriva/manbo-labs-creation.html
ici un journal en avait parlé https://linuxfr.org/~JRM/25998.html
Tu as en synthèse ce qui en est sorti sur http://blog.mandriva.com/2008/04/08/bits-and-pieces-about-th(...) La 2008.1 Spring inclut les travaux qui en sont sortis (sur gcc, kernel, rpm...), beaucoup de paquets ont maintenant une extension mnb1 et non plus mdv, comme ont pu le remarquer beaucoup d'utilisateurs de Mandriva Linux.
Cela va continuer sur le kernel pour la 2009.0 comme embrayé sur http://wiki.mandriva.com/en/Manbo_Core2_kernel
Donc oui, ça avance, il n'y a pas de communication particulière à faire pour l'instant à ce que j'en vois sur le net.
De toute façon, c'est surtout un travail de coordination, plus facile à faire entre 2 entités que dans un magma où Mandriva n'aurait pas forcément son mot à dire. L'important est qu'il y ait des choses de faites, les échos que j'en ai eu à Solutions Linux sont plutôt bons, les résultats se sont vus dans la Spring.
En aparté, tu sais, Mandriva est une société, elle communique comme elle veut et ne te doit pas de comptes ou d'explications, quand bien même elle bosse dans le libre : son meilleur livrable reste les logiciels libres produits et la distrib' qui profite à tous. Moi aussi à une époque j'aurais voulu plus de communication, puis en tant que simple utilisateur je suis devenu rationnel : cela ne me regarde pas forcément et ce n'est pas à moi d'exiger cela ;-)
Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 1.
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Je n'ai jamais conclu que c'était un échec !
Où j'ai dit ça ?
J'ai dit que je n'en savait rien !
J'ai dit que je n'en savait rien !
Où tu vois une conclusion ?
Maintenant, merci pour les informations que tu nous donnes. Elles indiquent que ma PRÉDICTION (et non conclusion) de l'échec de la collaboration entre Mandriva et TurboLinux était fausse.
> et ne te doit pas de comptes ou d'explications
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Merde, je peux dire des trucs sur des choses même si ces dernières n'ont pas de compte à me rendre.
J'ai jamais demandé à Mandriva où autre de rendre des comptes sur la collaboration entre Mandriva et TurboLinux.
Sûr que tu as critiqué MS-OOXML, pourtant MS-OOXML n'a pas de compte à te rendre (à moins que tu ais payé MS pour MS-OOXML...).
> Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
N'hésites surtout à nous tenir informé [1]. Tu peux dire que ma PRÉDICTION était fausse et te foutre de moi. Mais n'invente pas une conclusion que je n'aurais jamais faite.
[1] : Ceci ne te demande pas de me rendre des comptes, c'est seulement une invitation à nous tenir informer. Tu peux évidemment te torcher le cul de cette invitation.
[^] # Re: La réponse d'Aaron Seigo
Posté par BAud (site web personnel) . Évalué à 4.
Pour le 1), on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)
Cela peut se comprendre ainsi, en forçant le trait :
a) des tentatives ont foiré, par exemple celle de Mandriva et TurboLinux
b) il y a eu déjà des tentatives, par exemple celle de Mandriva (d'ailleurs où cela en est-il, cela porte-il ses fruits ?)
Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions, la réponse que tu me fais le démontre bien, tu vas même au plafond ;-) (un peu comme le double-jump aux dérivés libres de ioquake3)
Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé, mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Je ne te rendrai pas de comptes, mais je me renseignerai, ne t'inquiète pas, pour mon info (et je ne te dirai peut-être rien, na :p ou pas).
et je vais ouvrir un autre thread tout en bas pour les sujets constructifs :D https://linuxfr.org/comments/932269.html#932269
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
J'ai admis qu'il y a avait peut-être (voire manifestement) une erreur de formulation.
J'ai clairement, il me semble, rectifié ce que je voulais dire.
Je m'excuse encore de m'être mal exprimé.
Par pitié, ne parlez pas de mauvaise fois, lorsque je veux dire quelque chose je le dis.
> Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
http://linuxfr.org/comments/931937,1.html
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.(*)
Donc j'ai aucun avis si ça a réussi ou non.
(*) : c'était vrai au moment du post.
> tu peux l'assumer hein.
Très bien, j'assume avoir mal formulé, j'ai corrigé déjà une fois, je veux bien le refaire. J'ai aucun problème à reconnaitre mes erreurs. J'ai aussi beaucoup de respect pour ceux qui reconnaissent leur erreur il est donc normal que je reconnaisse les miennes.
Mais ce que je n'ai pas voulu dire, je n'ai pas voulu le dire. Point barre !
> tu peux l'assumer hein.
J'assume parfaitement ma mauvaise prédiction.
Si tu veux te foutre de moi car ma prédiction était fausse, fait le.
Je ne te critiquerai pas dans la "mamoeuvre", même si évidemment je n'apprécierai pas ça.
M'enfin, j'assume ma mauvaise prédiction.
Par contre, je ne m'excuserai pas sur ma mauvaise prédiction. Ce n'était qu'une prédiction.
> Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions,
Quelle conclusion ?
A toi d'assumer, puisque ça fait deux fois que tu parles de conclusion, où as-tu vu que je faisais une conclusion sur le deal Mandriva et TurboLinux ?
Assume : cherche et trouve !
Assume : si tu ne trouves pas, excuse toi.
> tu vas même au plafond ;-)
J'ai horreur qu'on me prête des propos que je n'ai pas tenu.
Je comprend bien qu'on puisse faire des erreurs (moi, toi, tout le monde).
Mais arrête de dire (comme encore un fois ici) que j'ai fait une conclusion sur le deal entre Mandriva et TurboLinux.
En passant, prêter des propos à une personne alors qu'elle ne les a pas tenu est de la diffamation. Ne t'inquiète pas, je ne vais pas t'attaquer en justice pour ça. Mais merde, c'est grave !
> Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque
J'ai déjà dit que je n'avais aucun élément. Merci (ça doit être la troisième fois que le dit...) d'avoir apporté des éléments.
Et alors ?
J'assume mon avis de l'époque.
Lorsque j'ai écrit "on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)", oui je m'attendais à ce que le deal entre Mandriva et TurboLinux ait foiré. Je m'y attendais. Ma pensée était aussi sur ma prédiction. Je n'ai aucun problème de le reconnaitre. Mais ce n'est pas une conclusion sur le deal entre Mandriva et TurboLinux (Diantre, il y avait où en est ce truc ?).
> tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé
Je vais te le dire tout net :
- je t'emmerde, je dis ce que je veux. Je n'attend pas ta demande, ni aucune demande.
> mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Tu fais très mal les conclusion des autres.
Juste en passant, quand Mandriva 2008.1 est sortie avec FF 2 (NB: Ubuntu 8.04 n'était pas sorti) il y eu des critiques pour dire que Mandriva aurait dû sorti avec FF 3.
J'ai dit que je trouvais normal que Mandriva 2008.1 utilise FF2.
Mais ça évident tu n'as remarqué. Tu fais une lecture sélective et après ne rate pas une occasion de chier une pendule.
J'ai dit plus d'une fois que je préfère l'époque post-Duval de Mandriva à l'époque Duval.
Mais ça encore une fois tu oublies.
J'ai dit que je m'attendais à voir un rebond de Mandriva car Mandriva fait, il me semble, globalement un bon boulot aujourd'hui.
Mais ça encore une fois tu oublies.
Si tu as la moindre information sur un regain de forme de Mandriva, donne les. N'hésite pas une seconde.
Si c'est l'inverse et que ma prédiction est fausse, donne les infos, fous toi de ma gueule.
Ce sont des informations sur des fais, elles sont toujours les bienvenues.
Pourtant, si j'étais aussi diabolique que tu veux le faire croire, pour justifier qu'on m'insulter de mauvaise fois, etc, pourquoi tu ne dis rien lorsque je dis quelque chose de positif sur Mandriva ?
Mais non rien. Ce qui est normal en fait. Mais ce qui n'est pas normal c'est de venir systématiquement me chercher des poux dans la tête.
Il y a eu "fiasco SSL" et certain disait "je vais passer à Fedora" d'autres disait "je vais passer à Mandriva". À ces derniers je n'ai pas dit "tant qu'à changer de distribution, passez à Fedora". Pourquoi diable je n'ai pas fait ça alors que je suis diabolique de mauvaise fois, et gnagnagna et gnagnagna ?
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
Oui, j'assume ma prédiction et la remet ici.
Je n'attend pas que mes prédictions soient confirmer pour "au moment opportun" dire "je vous l'avais dit".
[^] # Re: La réponse d'Aaron Seigo
Posté par Marc Poiroud (site web personnel) . Évalué à 3.
Ouvre un skyblog !
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . Évalué à 2.
# Assimiliation
Posté par Marc Poiroud (site web personnel) . Évalué à 3.
-- The Borg, Star Trek: The Next Generation episode "The Best of Both Worlds" (1990)
Voilà ce que me fait penser MS.
[^] # Re: Assimiliation
Posté par ciol . Évalué à -1.
# Rolling Release Distros
Posté par Ririsoft . Évalué à 8.
Mais quand est-il des gens qui utilisent des distros dites "Rolling Release", comme Archlinux, Gentoo, Debian Unstable pour les plus connues et tant d'autres (Foresight, Sourcemage ...) ? Et bien tout simplement ils n'en ont rien à faire !
J'ai de plus en plus de mal avec ces distros qui nécessitent une mise à jour (jamais simples) tous les 6 mois !
Autant je comprend parfaitement RHEL, Suse LE et Debian stable. Compatibilité binaires, ABI, API etc .. OK !
Autant je ne comprend pas du tout Ubuntu Desktop ou Fedora ou Mandriva et leurs releases tous les 6 mois.
Pour les entreprises oui, pour les geeks/developpeurs non !
Qu'on ne me dise pas que les gens cherchent la stabilité! Ils passent leur temps à chercher des backports ou a ajouter des dépots pour tester la dernière beta de kde4 ou banshee1 ou autre !
En plus Ubuntu et Fedora délivrent des logiciels en version beta (gdm, Firefox entre autres). Et puis franchement qui n'a pas eu des problèmes avec des mise à jour pendant le cycle régulier d'Ubuntu ou autre ? Une "Rolling Release" distro telle qu'Archlinux ou Gentoo n'a rien à envier à personne en terme de stabilité !
- Avec une "Rolling Release" distro c'est rare, mais tu peux avoir des problèmes lors de mises à jours.
- Avec une "Cycle Release" distro c'est rare, mais tu peux avoir des problèmes lors des mises à jours pendant le cycle de vie d'une release, et EN PLUS tu te tapes tous les tracas d'une mise à jour de release !!!
Quelqu'un peut m'expliquer pourquoi certains aiment tant mettre à jour tous les 6 mois ?
Quelqu'un peut m'expliquer ce qu'apporte une "Cycle Release" distro par rapport à une "Rolling Release" ?
Enfin et je terminerai là-dessus :
Je me balade beaucoup sur les bug tracker d' "Upstream", Gnome en particulier. C'est impressionnant le nombre de contributions de Fedora. C'est gens là font beaucoup avancer le libre et sont vraiment discrets (ça me plait). Tout ce que fait Ubuntu c'est "ce bug a aussi été reporté sur launchpad".
Notre "ami" Mark aiderait plus en passant plus de temps Upstream qu'en bloggant dans le vent.
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 2.
D'un point de vu utilisateur, je comprend que tu ne cromprennes pas :-)
D'un point de vu développeur, c'est sensé.
[^] # Re: Rolling Release Distros
Posté par Ririsoft . Évalué à 2.
Quand je regarde Arch et la taille de la communauté des devs, je suis impressionnés par le boulot fait !
Et aussi le plus les paquets sont Vanilla (non patchés) le moins tu as de boulot. Avec un bon gestionnaire de paquets, changer la version dans un fichier suffit la plus part du temps. Fedora l'a bien compris et c'est une des raisons (pas la plus grande) pour lesquels ils poussent tout upstream.
Mais je dérive vers une autre discussion : paquets patchés ou pas ? Je devrais aller poster dans le thread sur la faille SSL ...
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 2.
Ce n'est pas ça le plus important.
Avec une release (et donc la phase de développement de celle-ci) tu peux te permettre de tout casser. Tu peux changer de compilateur (ce que fait encore une fois Fedora avec F9), etc.
Il y a une grande liberté et donc aussi une grande efficacité pour le développement (on ne se contente pas de packager, on va plus loins).
Enfin les mises à jours de distribution n à n+1 avec Fedora sont fait hors du système qui va être mise à jour. Tu peux alors passer de ext3 à ext4, changer le format rpm, changer init, etc. Il y a une grande liberté de développement.
Les développeurs Fedora ont une Fedora stable pour le boulot de tout les jours (une F8 ou F9 typiquement). Et ils ont aussi une Rawhide (la branche de développement) pour coder/tester/etc. Si la branche de développement explose, ce n'est pas grave (c'est même courrant et c'est aussi ce qui fait le charme de Fedora pour beaucoup de contributeurs).
[^] # Re: Rolling Release Distros
Posté par Ririsoft . Évalué à 1.
Avec une Rolling aussi : il y a un dépot "testing" ou les devs font tout le boulot. En particulier quand un nouveau GCC sort il est testé localement par le développeur, puis mis dans testing pour que tous les développeurs (et utilisateurs du dépot) puissent tester. Si une recompilation du dépot est nécessaire alors c'est fait.
Quand un logiciel est jugé stable il monte dans la branche 'stable' et tout le monde en profite.
Certains logiciels montent plus vite que d'autres tu imagines bien.
> Il y a une grande liberté et donc aussi une grande efficacité pour le développement (on ne se contente pas de packager, on va plus loins)
Loin de moi de contester la qualité du travaille de Fedora. Je viens souvent leur piquer des idées. Mais je ne vois pas en quoi le fait qu'il y ait des releases améliore la qualité d'un paquet : tu bosses sur une version, tu apportes (ou pas) ta valeur ajoutée, tu tests et tu délivre le paquet ! Il y a besoin d'une release pour ça ? Un repo de testing c'est pas suffisant ?
Je ne vois pas le rapport entre qualité, valeur ajoutée et release/rolling release ?!
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 2.
Ce n'est pas pareil.
Avec Fedora, du jours au lendemain (ou presque) tous les paquets sont compilés avec gcc 4.3.
Il y a un release manager (ou un truc dans ce goût) pour tout coordonner. Ce n'est pas qu'un "bac sable".
> Mais je ne vois pas en quoi le fait qu'il y ait des releases améliore la qualité d'un paquet
Je ne parle pas de qualité, mais de développement.
Ces aspects ne sont pas forcément liés.
> tu bosses sur une version, tu apportes (ou pas) ta valeur ajoutée, tu tests et tu délivre le paquet !
Ben justement, Fedora ne fait pas que ça.
Fedora prends des trucs en CVS, bosse sur Rawhide, contribue upstream, etc.
Et tu as bien remarqué que Fedora contribue beaucoup en upstream. Fedora ce n'est pas et ça ne veut pas être seulement packager des logiciels.
> Il y a besoin d'une release pour ça ? Un repo de testing c'est pas suffisant ?
Fedora a aussi son dépôt testing...
Mais ce n'est pas suffisant.
Si t'es très content avec arch, et je n'en doute pas, pas de problème, éclate toi.
[^] # Re: Rolling Release Distros
Posté par Gof (site web personnel) . Évalué à 5.
> compilés avec gcc 4.3.
En quoi est-ce un avantage ? (surtout s'il faut de toute façon attendre 6 mois)
De plus, si c'est nécessaire (pour des problèmes de compatibilité aprsè une update de la glibc par exemple) le système de dépendances fera son boulot.
> Il y a un release manager (ou un truc dans ce goût) pour tout coordonner.
Il y a aussi des coordinateurs dans Archlinux.
> Fedora prends des trucs en CVS, bosse sur Rawhide, contribue upstream, etc.
Archlinux fait aussi ça dans la mesure de ses moyens.
Mais ça n'a rien à voir.
> Fedora a aussi son dépôt testing...
> Mais ce n'est pas suffisant.
Et pourquoi n'est-ce pas suffisant ?
(Dans archlinux, il y a les dépots release, core, testing, et experimental, perso je suis en testing)
Bref je n'ai toujours pas vu d'arguments convainquant pour un système de releases tout les 6 mois ?
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à -3.
Disons que Fedora est maso et aime ça.
J'aime ça aussi.
> Bref je n'ai toujours pas vu d'arguments convainquant pour un système de releases tout les 6 mois ?
Il y en a aucun.
Mais bizarrement les distributions les évoluées utilise les releases tous les 6 mois.
Mais c'est seulement le hazard.
[^] # Re: Rolling Release Distros
Posté par Julien . Évalué à -1.
Entendre Fedora
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 1.
Par exemple, il y a OpenSuse.
Mais peut-être que tu fais une fixation.
[^] # Re: Rolling Release Distros
Posté par Julien . Évalué à 3.
Elles ont juste des buts et des points forts différents.
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 2.
Pour gentoo, ta remarque est pertinante.
Pour Ubuntu, bof.
[^] # Re: Rolling Release Distros
Posté par Julien . Évalué à 3.
Est-ce que tu pourrais m'en dire plus ?
[^] # Re: Rolling Release Distros
Posté par IsNotGood . Évalué à 1.
Très bonne remarque.
Ma notion d'évoluée n'est peut-être pas la tienne et je ne prétend pas que la mienne soit forcément plus pertinente qu'une autre.
> Est-ce que tu pourrais m'en dire plus ?
Si c'est pour partir sur un débat sur ce qui est évolué ou non, je préfère éviter. Ça va être une interminable "bagarre" et rien que de l'envisager ça me fatigue :-)
[^] # Re: Rolling Release Distros
Posté par Julien . Évalué à 3.
Alors, qu'est-ce qu'une distribution iznogoodévoluée ?
[^] # Re: Rolling Release Distros
Posté par 2PetitsVerres . Évalué à 4.
Mais bizarrement les distributions les évoluées utilise les releases tous les 6 mois.
Mais c'est seulement le hazard.
Oui, et windows a plus de 90% de parts de marché, et si 75% des gens bouffaient de la merde, je me dirai que la merde, ça doit être vachement bon.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Rolling Release Distros
Posté par lezardbreton . Évalué à 2.
[^] # Re: Rolling Release Distros
Posté par Ririsoft . Évalué à 1.
- Tu peux très bien avoir ce mode de fonctionnement avec une Rolling Release. C'est toi qui choisit quand tu update et ce que tu update (failles de sécurité entre autres). Certains font des updates tous les jours, d'autres tous les mois, et d'autres tous les ans !
Si tu n'as pas fait d' update depuis très longtemps et que tu veux updater juste un paquet, peut-être auras tu besoin de le recompiler pour qu'il passe avec ta toolchain ... Ce qui est fait automatiquement sous Gentoo et très facilement sous Arch. Tu disposes aussi de paquets avec les vielles versions de softs libs en particulier gcc3 si tu veux ...
En ce qui me concerne j'update tous les jours, mais j'ai une blacklist de paquets critiques pour moi à ne pas updater (pacman permet ce genre de fonctionalité comme beaucoup d'autres d'ailleur).
- J'ai le sentiment que ce type de comportement ne concerne qu'une petite partie de gens sérieux comme toi et que beaucoup d'utilisateurs d'Ubuntu cherchent surtout la nouveauté : j'en veux pour preuve le buzz assourdissant à chaque sortie de ce type de distro.
Enfin je te retourne la question : tu feras comment quand Mandriva ne supportera plus les mises à jour de ta version ?
[^] # Re: Rolling Release Distros
Posté par lezardbreton . Évalué à 3.
En fait, ne mettre à jour que tous les 6 mois me convient de plus en plus. Généralement, j'ai fait tellement de conneries sur ma machine à installer des softs dont je me fous que je préfère repartir de 0. Je crois que j'étais friands des nouveaux softs à l'époque où il y avait vraiment de l'innovation et en ce moment, c'est franchement le vide complet.
Arch et Gentoo permettent effectivement d'être fin et en ce sens sont très intéressantes. Par contre, j'aurais bien aimé en plus une approche à la BSD où une distinction claire est faite entre système et logiciels autour. C'est évidemment possible sous Gentoo, mais ça demande plus de travail.
[^] # Re: Rolling Release Distros
Posté par Ririsoft . Évalué à 1.
Là nous nous retrouvons :-)
Il y a vraiment une chose qui m'empêche d'être sous FreeBSD c'est le support Hardware plus restreint que sous Linux. J'ai malheureusement une carte Wifi exotique tout juste supportée sous Linux et qui ne fonctionne pas avec la dernière version de FreeBSD. Je l'ai bien cherché aussi : j'ai acheté ma carte à la fnac sans regarder !
Ceci dit Arch et Gentoo sont très proche des BSD dans l'esprit.
Quand à l'innovation actuelle dans le monde Opensource je ne sais pas trop quoi en penser. Avec toutes la com' (blogs, news, ...) je suis un peu perdu. Mais quand j'utilise un Windows ou un Mac j'ai le sentiment que les logiciels libres ont pris un ascendant techniques net. Peut-être que je m'emballe ...
[^] # Re: Rolling Release Distros
Posté par ciol . Évalué à -3.
Sachez, qu'entre les "cycle release" et les "rolling release", il y a les vraies distros qui savent faire la part des choses (aka base stable + dernières versions des applications tierces) comme Gniarf Linux, Lapwing Linux et Draco Gnu/Linux (je ne compte pas Gentoo qui est une distribution source, PC Linux OS qui n'écrit pas clairement son modèle de développement sur sa page d'accueil, ni foresight Linux idem que PCLinuxOS).
# Un autre commentaire
Posté par Spyhawk . Évalué à 3.
http://dev-loki.blogspot.com/2008/05/re-ubuntus-pipe-dream-t(...)
# synchro ou suivre ou avancer
Posté par BAud (site web personnel) . Évalué à 2.
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
[1] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-ipw3945 ancien pilote
[2] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-iwlwifi pilote plus récent + pile wifi
[3] https://linuxfr.org/~bersace/25359.html utilisation de ppa
[4] http://julien.danjou.info/blog/index.php/post/2007/08/16/Deb(...)
[^] # Re: synchro ou suivre ou avancer
Posté par GeneralZod . Évalué à 2.
http://en.opensuse.org/Build_Service
C'est effectivement très pratique, pour les projets voulant offrir des paquets pour diverses distributions ou tester la compilation sur une autre architecture.
Sinon, FedoraProject a sa propre ferme de compilation, actuellement Koji
autrefois Plague. FedoraProject est recompilé dans sa totalité à plusieurs reprise lors du cycle de développement, avec l'envoi d'un mail au mainteneur si la compilation automatique échoue.
Koji offre également la possibilité de créer des dépôts personnels mais cela n'est pas activé par défaut. L'outil est capable de compiler des paquets pour n'importe quel distribution utilisant RPM, il suffit de créer un fichier de configuration pour le chroot de compilation (Mock).
> Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms
FedoraProject n'utilise pas dkms pour diverses raisons.
Les modules noyaux (kmod) sont générés à l'aide de l'outil kmodtool, et il existe également des akmod pour simuler un comportement à la dkms. Tu as un service akmod qui au démarrage, teste l'existence d'un module précompilé et qui si nécessaire recompile le src.rpm.
[^] # Re: synchro ou suivre ou avancer
Posté par BAud (site web personnel) . Évalué à 2.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . Évalué à 2.
Tu peux sourcer ?
Donne des cas précis.
Parce qu'en fait, j'ai l'impression que tu n'as pas d'argument pour critiquer le processus (ou l'organisation). Tu es seulement déçu. Je veux bien l'entendre, mais ce n'est pas à mon avis suffisant pour remettre en cause le processus et son application.
Puis tu sembles totalement faire l'impasse sur les distributions qui ne montent pas en version de noyau et font des backports (RHEL, SLES, etc les distributions "entreprise"). Pour ces dernières, ça marche exactement comme le dit Andrew Morton.
> Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
Dans ce domaine, la distribution Fedora fait une grosse contribution (les noyaux ont toujours les derniers patchs wifi ; normal c'est un employé Red Hat qui maintient wifi).
> - les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
Et ?
La priorité de l'upstream est mise sur ce qui va marcher, pas sur ce qui ne marchera jamais bien. Ça me semble très normal.
> - Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
C'est le boulot de Mandriva (vu sa cible). Ce n'est pas le boulot d'autres distributions.
Tu as peut-être mal compris Andrew Morton. Il n'a pas dit que les distributions on tobligation de faire ce que fait Mandriva. Il a voulu dire que l'upstream sera plus concentré sur le développement que de fournir un noyau directement utilisable par les distributions. Les distributions doivent donc s'attendre à fournir du boulot et non seulement piquer le noyau sur http://www.kernel.org/ . Une distribution peu bloquer la sortie d'une nouvelle version s'il y a un driver très utilisé qui sucks. Le noyau vanilla ne le fera pas (ou beaucoup moins).
> Tout l'intérêt de dkms est de "gentoo-ifier" les modules
Ce n'est pas toujours vraiment intéressant (or pour voir si la recompilation marche).
Fedora a un système pour "récupérer" les modules de l'ancien noyau qui ne sont pas dans le nouveau lors de la mise à jours. Ceci est fait si l'API utiliser par le module n'a pas changée.
On retrouve ses modules dans /lib/modules/`uname -r `/weak-updates après la mise à jour.
NB: pour Fedora dkms n'est pas très intéressant puisque Fedora a souvent la dernier version du noyau. Donc si le système "weak-updates" ne marche pas, il faut très probablement des nouveaux sources pour le module et donc repackager le module (pas seulement le recompiler).
Je crains que les choses sont plus compliquées.
Il y a les distributions communautaires qui veulent être très proche de l'upstream (Fedora, Gentoo, etc). Les mi-communautaire / mi-commerciale qui mette leur plus value à une version du noyau (pilote avec ancienne pile wifi, etc) pour la satisfaction de leurs clients. Ces dernières ont une mission "produit" plus marquée.
Il y a les distributions presque exclusivement commerciale : RHEL, SLES, etc.
De quoi tu parles ? :-)
[^] # Re: synchro ou suivre ou avancer
Posté par BAud (site web personnel) . Évalué à 2.
comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva et par rapport à mon titre de ceux qui "suivent" et non qui avancent à la même cadence que l'upstream : cela concerne les distribs' stables (donc peut concerner Fedora 7, Fedora 8, maintenant Fedora 9 mais pas rawhide).
Fedora 8 en est au 2.6.23.1 d'après distrowatch. Dans cette branche Andrew Morton en est au 2.6.23.17, non pris en compte tel quel (si j'en crois distrowatch). Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Sur Mandriva Linux 2008.1, il y a le 2.6.24.4, Andrew en est au 2.6.24.7 et je ne crois pas qu'il sera pris en compte, cela passera par des backports au mieux ou sinon il y a le kernel-linus-2.6.25-0.rc6.1mdv (principalement upstream).
packages.ubuntu.com est down, je n'ai pas vérifié mais je ne pense pas qu'ils soient à la dernière version non plus.
Je ne remets pas en cause, je constate simplement des difficultés rencontrées par les distributions à accrocher au processus : cela sert pour le choix initial du kernel, ensuite chaque distrib' a sa politique de mise à jour et de constitution de "son" kernel (backports, dkms). Mandriva va aussi chercher des pilotes qui n'ont pas encore fait l'effort d'être inclus dans le kernel (il y a aussi de l'upstream du kernel hein ;-) ).
Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
Pour les dkms, je notais simplement un moyen supplémentaire de mettre à jour par morceau le kernel plutôt que d'attendre qu'un nouveau kernel soit packagé. Ayant bossé sur l'upstream de module, c'est intéressant quand ton code n'a pas encore été poussé dans le kernel et qu'une distrib' s'y intéresse (le paquet dkms permet de constituer le backport directement pour une floppée de versions de kernels, même si ce n'était pas l'utilisation initiale prévue pour dkms).
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . Évalué à 2.
OK, désolé.
Mais ça ne reste toujours pas claire.
Que pointes-tu ?
Un manque de moyen ?
Des conflits dans les rôles ?
Je comprend mal.
> Fedora 8 en est au 2.6.23.1 d'après distrowatch.
Distrowatch est une bonne source d'info. Mais pas toujours exacte.
Actuellement pour F8 c'est un 2.6.24.7 (mise à jour du 14/05).
Je ne sais pas si un 2.6.25 est prévu. Mais il ne faudra pas être surpris s'il y en a un. S'il n'y a pas encore de 2.6.25, j'image que c'est à cause d'un manque de moyen (ou d'autres priorités, ou une meilleure opportunité qui se présentera un peu plus tard, etc).
> Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Ce n'est que temporaire. Il y a évidemment un délais entre les releases upstream et Fedora.
Le 2.6.25.3 est dans les mise à jours (de F9).
Le 2.6.25.4 est en préparation :
http://koji.fedoraproject.org/koji/buildinfo?buildID=49409
> Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
C'est /sbin/weak-modules (un script sh) qui le fait (appelé par les scripts d'installation du rpm kernel). /sbin/weak-modules est dans module-init-tools.
Mais, tel est Fedora, bourré de surprise :-)
L'appel à weak-modules est mis en commentaire depuis peu de temps .
J'ignore précisément les raisons.
Je n'ai trouvé que ça comme info :
http://www.redhat.com/archives/rhl-devel-list/2007-March/msg(...)
FWIW, weak-modules will go away in a future Fedora. The plan is to replace it with a much more comprehensive online driver update tool that will do a lot more than just create symlinks - more information when I have an example to share... :-)
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . Évalué à 2.
Bien évidemment.
Mais un "état major" qui fixe ce qu'un ensemble de distribution de faire : c'est non.
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . Évalué à 2.
Voir ici pour d'autres infos :
http://www.kerneldrivers.org/KernelDrivers.org
# Re:
Posté par IsNotGood . Évalué à 2.
4. The Premise. The vision behind DCC, which is indeed compelling, is that it would provide a common platform for certification, and that the distros that make up the DCC would all ship exactly that same core. But it strikes me that this approach has never worked in the past. In fact, every distro ALWAYS modifies elements of the core, and with good reason. And while we would love that not to be the case, the truth is that the reasons to specialise outweigh the benefits of homogeneity. Much as it may be compelling, the common core idea is ultimately flawed, because it's not just the bits at the core that matter. An ISV that certifies an OS is not just certifying the pieces on which it's app depends. It's also certifying the *environment* which it will support, which includes installer, documentation, even packaging. Screenshots, for example, won't be useful unless they reflect all of the certified OS's, and that's not possible in the DCC model. There have been several examples of places where this idea has failed. United Linux is one.
Joli retournement de veste Monsieur Mark Shuttleworth.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.