Et bien lorsque les developpeurs les plus pointus techniquement (en l'occurence les devs du kernel, de glibc, de gcc) considèrent que pour avoir un logiciel de bonne qualité sous Linux, il ne faut pas tenter la compatibilité binaire à 100% mais plutôt se décarcasser sur la compatibilité avec les standards d'api (ANSI C, aka C89, C99, POSIX, fd.org ..., qu'on est encore loin d'avoir atteint), et que Monsieur Gaël Duval clame à l'inverse qu'il faut changer tout ça et se focaliser sur les binaires, excuse moi, mais je fait plutôt confiance aux developpeurs du kernel, de la glibc, de gcc etc.
Que j'ai tort ou raison, la faible représentation des devs mdk dans ces projets cruciaux fait que ces priorités ne changeront pas (au-delà de LSB).
Ceux qui font évoluer les choses ne sont pas les commercials qui disent leur opinion sur leur page perso, mais les developpeurs (si tu veut vraiment de la compat binaire, au lieu de raler contre les choix devs, tu n'a qu'à y travailler).
Chacun à le droit d'apprécier ou pas la mode autour d'Unbuntu. On dirait qu'Unbutu parait intouchable parce que dérivée de Debian.
Oui, mais il est assez insultant pour ses utilisateurs de qualifier l'engoument pour Ubuntu d' « effet de mode » ou de « hype ».
Puisque Ubuntu vise en partie le même public que Mandriva (le grand public / les utilisateurs novices), il me semble qu'il serait plus intelligent de la part de Gaël Duval de considérer qu'Ubuntu répond à des attentes de ce public, d'analyser objectivement les raisons de son succès (!= se contenter de l'attribuer à la "hype") pour améliorer son propre produit.
On (utilisateurs d'Ubuntu) s'evertue dans cette dépêche à expliquer ce qui nous a séduit chez Ubuntu ou ce qui nous a déplu dans l'image (ou la réalité, peu importe) de Mandriva. Et aucun Mandriviste pour en tirer parti. Dommage.
Je dirait qu'une des raisons du succès d'Ubuntu est l'impression -fondée ou illusoire- pour les utilisateurs d'être vraiment écoutés, d'être le noyau qui fait progresser la distribution: choix et décisions en fonctions de nos besoins effectifs, impression d'être partie prise et partie prenante dans le processus etc.
C'est que c'est ce qui nous a manqué chez Mandriva que nous avons finalement quitté: fondée ou illusoire, l'impression d'un mode de developpement opaque, corporate, d'une ironie présomptueuse des dirigeant comme celle de GD dans son texte, ambiguités sur le "club", les objectifs etc. Votre attitude n'arrange rien à cette image qui colle à mdv.
Il ne faut pas se contenter pas de dire à longueur de post "mdv est une distrib qui donne la parole aux users, une distrib basée sur la communauté contrairement à votre impression": il faudrait peut-être se demander pourquoi elle n'a pas cette image. Il faudrai peut-être se demander pourquoi les utilisateurs migrent par miliers chez Ubuntu (et nos commentaires devraient vous aider, non ?).
avait fait du logiciel propriétaire (tel Launchpad)
Oui sauf qu'on en parle pas de logiciel propriétaire pour un service (tu a les sources du site web de mandriva ou de red hat ? de google ?) et que ce service est simplement en phase initiale de developpement, que son code sera ouvert lorsque "releasé".
En attendant Launchpad fait mouche et crée une effervecence dans la communauté des utilisateurs. Ce serait un peu dommage de ne pas s'en rendre compte, ne pas se demander si ça répond à un besoin réel.
par une entreprise commerciale dont l'existence repose sur le mécénat. Pour l'instant, on ne sait pas ce que Canonical vaudrait sans les fonds de Shuttleworth.
Canonical est lancé avec les fonds de Shuttleworth et c'est normal. Connais tu une entreprise qui soit lancée sans capital ?
Par contre Ubuntu n'est pas une entreprise commerciale, et ce qui fait son vrai capital, selon moi, c'est une communautré d'utilisateurs engagés et enthousiastes. Finallement ce sont eux qui font l'effervécence et la "hype" dont parle Duval et qui fait défaut à Mdv.
Tout ceci à de quoi intriguer. Il est normal que des gens comme Duval disent ce qu'ils en pensent.
Bah oui, et ce qu'en pense Duval, visiblement, c'est qu'Ubuntu est un pur effet de hype, de poudre aux yeux orientée "choix de la couleur de fond d'écran et idolatrie des spationautes". On en déduira que selon lui les utilisateurs d'Ubuntu sont des cons dupés par le marketing qui ne savent pas juger d'un bon produit. Très bien, mais j'espère qu'il ne souhaite pas faire venir les utilisateurs chez lui avec un tel discours... vu le problème d'image (fondé ou pas) de mdv qui est apparu dans les autres commentaires, son attitude est suicidaire.
Comme disait un commentaire plus haut, la FAQ de Shuttleworth est vraiment une FAQ, elle répond vraiment aux questions qui se posaient fréquement dans la communauté Ubuntu (et Debian). C'est tout à son honneur d'avoir su les entendre pour y répondre précisément. Ça fait parti des choses qui nous donnent l'impression d'être entendus.
Le texte de Gaël Duval parrait en revanche lancé de sa tour d'ivoire, et ne répond pas aux questions que les utilisateurs se posent sur mandriva (eg. la couleur du fond d'écran n'est une question vraiment vive que chez ubuntu) mais se contente de "dire ce que Duval en pense" (d'Ubuntu) ou de se moquer légèrement des Ubuntistes. Je trouve que c'est une super mauvaise idée d'en avoir fait une dépêche de première page On approche les 300 commentaires, signe caractérisé d'une discussion stérile (aka, "un troll").
> j'avais des problèmes récurrents avec mplayer et Ubuntu ... j'ai du les compiler dans /usr/local. debian-marillat marchant mal avec ubuntu
Oui ubuntu est jeune est c'est en train de se mettre en place. Maintenant c'est ok, il y a PLF.
> avec blender (je veux la dernière version) --> ~/.local/blender/
Ça c'est une autre question (les paths d'installation). Tu peut bien l'installer system-wide (/usr ou /usr/local) comme le ferait d'ailleur un package venant d'une autre distrib (si tu avait la fameuse "compatibilité binaire"). Mais tu hésite à le faire pour ne pas pourir ta distro, ce que je comprend bien. Mais tu aurait autant hésité (pour les mêmes raisons) avec un package binaire "alien".
Dans tout les cas, vouloir plus de compatiblité binaire c'est incompatible avec le fait d'utiliser en permanence les versions bleeding edge des logiciels (puisqu'il faut un minimum de stabilité des api et abi).
> et lorsque c'est gnome ou kde qui manque, peut on envisager de le compiler dans /usr/local ?
Bin oui, c'est ce que font FreeBSD et OpenBSD par exemple.
> Il ne suffit pas d'éluder une question pour affirmer qu'elle ne se pose pas.
Hein ? j'élude quoi ?
J'explique (en argumentant) que la compatibilité binaire entre les diverses distros demanderai un travail trop important pour qu'on puisse le faire, donnerai un résultat insuffisant et instable, et ne serait pas utile car il existe des solutions (au problème nommé: faire tourner l'appli x version y sur la plateforme z) qui marchent très bien (utiliser un package standard, ou installer par les sources, ou récupérer le package non officiel d'un autre utilisateur qui l'a construit).
> Il faut que les utilisateurs puissent installer rapidement et simplement des programmes depuis le web, depuis un CD-ROM.
Tout à fait, et c'est ce qu'ils font déjà. Tu utilise LFS ou quoi ?
> Maintenir plus de 10000 paquets est un travail fastidieux et inutile
OK alors on résume: si chaque paquet n'était packagé qu'une seule fois, il n'y aurait tout simplement qu'une seule distrib. Ça ne me semble vraiment pas souhaitable.
Parceque le fait de produire le binaire, c'est peanuts, c'est peut être 5% du temps passé sur la préparation du paquet (le tester, le mettre à l'épreuve, le documenter, ...). Faire le binaire + préparer le paquet (test, debug etc.) c'est bien le travail des distros. Autrement dit: polir, debugguer, améliorer les logiciels (et accessoirement les compiler et packager). S'il y a moins de personnes qu'ils le font, alors les logiciels seront moins bons (je parle des tests bien sûr, parceque la compilation/packaging, c'est maintenant totalement automatisé dans la plupart des cas).
Quand au "fastidieux et inutile", il faudra alors m'expliquer pourquoi un millier de developpeurs se pressent au portilion debian.
> Le monde propriétaire le fait. Ce n'est pas parce que la licence change quand ça change la technique aussi. C'est possible techniquement.
Un détail: dans le monde windows (aka "propriétaire"), on réimplémente / réinvente la roue sans cesse (ou se linke statiquement lorsqu'on a acheté une lib). L'essentiel des API/libs partagées sont celles d'un seul fournisseur, microsoft. Des miliers de boites réécrivent les mêmes fonctionalités, en permanence.
Dans le LL on mutualise le travail jusqu'au sang ; on fait des libs par centaines. On réutilise tant qu'on peut. On partage les fonctionalités.
Et c'est pour ça qu'avec un nombre de developpeurs beaucoup plus restreint, on arrive à un résultat très satisfaisant.
La contrepartie, c'est qu'il peut y avoir un jeu de dépendances très complexes entres les logiciels. Mais on s'en est toujours bien sorti parceque ce jeu de dépendance est établi à la configuration/compilation, par les sources. C'est astucieux, ça marche bien, et l'aspect fastidieux de la chose est
Maintenant, dans ces mêmes conditions, on pourrait travailler à avoir une compatibilité binaire approximative. Mauvaise idée: les ressources pour arriver à ce résultat seraient considérables: bien au delà de nos moyens, et bien au-delà de l'effort pour arriver à ce résultat sous windows (où les dépendances sont généralement nulles); et dans tout les cas, "approximatif" n'est pas suffisant: pourquoi souhaiter un environement fragile lorsqu'on à déjà quelque chose de robuste ?
> Le fait de distribuer des binaires un minimum permutables entre les distros ça ne retire rien du tout à ce qu'il est possible de faire
Mais si. Ça prendrai un temps infini, pour un résultat toujours douteux. Tu pense que les developpeurs kde/gnome/kernel/glibc sont incompétents lorsqu'ils disent que ce n'est pas un objectif pertinent ? Personellement je suis plutot content qu'ils travaillent à améliorer leurs applis, pas à bidouiller sur les binaires.
Pourquoi tu rale ? tu devrait plutot faire ce que tu dit puisque c'est si facile...
> le même binaire d'OOo 1.1.5 il tourne sur un windows
Cet exemple tombe à point. Les types d'OOo ont (un peu à la manière des éditeurs de logiciels propriétaires sous win32) tout ré-écrit, même leur propre toolkit graphique. C'est un travail ENORME. Un travail nécéssaire à l'époque, il n'y avait pas d'autres choix.
Même chose pour firefox, qui intègre un maximum de libs redondantes avec le système dans les tarballs binaires: ils peuvent se le permettre car leurs ressources (support financier, nombre de devs, ...) sont énormes, et parcequ'à leurs début il a fallu faire ça (pas le choix). Et encore, il s'agit d'appli ayant finalement relativement peu d'interactions avec le reste du système.
Maintenant les choses on changé, et je suis heureux que les developpeurs n'aient pas que ça à foutre ...
Il faut arréter de réver: combien d'appli gnome ou kde en C/C++ connait tu qui soient compatibles entres les distros majeures ?
Le mode de developpement des logiciels propriétaires sous win32 n'est pas adapté aux logiciels sous Unix libre (btw, ne pas oublier les *BSD), et ce qui est pour eux un besoin impératif (la compat. binaire) est pour nous totalement accéssoire.
Je me répete, mais bon j'ai pas l'impression que tu ai lu: la preuve: les logiciels propriétaires sous *nix s'en sortent très bien avec *nos* méthodes. À l'heure des machines virtuelles sous qemu pour 0 euros, ils peuvnt tous se payer un parc de compilation & tests pour les distribs majeures, ou trouver d'autres solutions: skype, kqemu, opera, sun jdk, nvidia, vmware, intel c++, oracle...
> Ben voilà, et si c'était simplement ça à remettre en cause ? ne changer les API que sur des choses vraiment majeure,
Mais c'est évidement remis en cause (par eux même), ce n'est pas quelque chose qui est arrivé volontairement. Les developpeurs ne se sont pas dit: "hé, les gars, et si on s'amusait à péter toute la compatibilité binaire dans la branche stable". L'exemple était là pour illustrer le fait qu'il est très dur, même pour des developpeurs chevronnés. Dans la plupart des cas, une simple correction de bug entraine un changement dont ne peut pas mesurer toutes les conséquences (cf. les raisons de la sortie de php 4.4 par ex.).
>> Or, pour mémoire, il suffit d'avoir seulement un kernel différent
> C'est justement ça qu'il aimerait changer.
Vu la superbe représentation des devs Mandriva sur LKML, c'est sûr que les coups de gueule de Gaël Duval sur son blog vont faire changer les chose :)
> si tu prend la situation actuelle (qui est justement critiquée) pour montrer que ce n'est pas possible
Je dit que ce n'est ni possible, ni intéressant.
Et je dit bien que ce n'est pas possible : donc dans la situation actuelle et les situations futures.
> Pourquoi nous on ne le pourrait pas techniquement ? tu m'expliques ?
Bon sang, mais j'ai passé 1/2 heure à l'expliquer juste au-dessus !
> Si déjà, pour les architectures courantes (x86, amd64, mac) du grand public
Ah, mais si tu cherche un système pour pécé seulement, grand public (seulement), dont l'ABI ne change jamais afin de faire tourner des logiciels propriétaires closed source, mon vieux, c'est tout vu. Windows est adapté à tes besoins.
Les softs MS eux-mêmes ne supportent que 2 ou 3 versions de windows au plus (cf. le futur ie7, ou office 2003 etc.), et pourtant leur modèle closed source les forces à garder des tonnes d'immondices (comme le DOS) pour assurer une compatibilité ascendante.
> Notes aussi que mac a trouvé une bidouille infame
Oui, pour le format des binaires. Maintenant si on parle de la compatibilité ascendante chez Mac (et même en ne restant que sur la série des Mac OS X), tu verra que ce n'est pas ça du tout.
> Pourquoi ? sauf cas où la faille touche justement l'API utilisée par les plugins, c'est justement l'exemple type où la compatibilité binaire ne devrait pas être cassée. D'ailleurs pour le coup, là, ça marche assez bien.
Simpe: parce que les types de firefox cassent très régulièrement l'API, et font des updates groupées (incluant du refactoring, pas uniquement les patches sécus). Cf. par ex. la cata. 1.0.4 -> 1.0.5. Et après l'arrivée prochaine de 1.5, je doute qu'ils maintiennent 1.0.* bien longtemps ("upgradez les gars").
Faut voir les proportions d'intervenants (et la mauvaise fois déployée), lorsqu'on emet une critique sur la distribution franco-française sur linuxfr...
La compatibilité binaire entre les distributions est une chimère, impossible et sans véritable intéret (oui, autoconf/automake/make/gcc permettent aux devs des distros de faire des binaires adaptés à leur environement):
- Il n'y a pas d' « instant t » pour les distributions: Debian met plusieurs années à sortir, Fedora et Ubuntu sortent tout les 6 mois, Mandriva tout les ans ... Or, pour mémoire, il suffit d'avoir seulement un kernel différent (il en sort un nouveau tout les 3 mois) pour ne plus être compatibles (les modules du kernel t+1 ne sont pas adaptés au kernel t).
Donc il est impossible d'avoir les mêmes versions des libs compilées avec le même compilateur, avec les mêmes patches, sur le même kernel, en même temps, et sur toutes les distros. À partir de là, la compatibilité binaire ne peut arriver que "par chance" ou "par hasard", comme dit Shutlleworth.
- Quand bien même il y aurai une « compatibilité binaire à l'instant t », en quoi celà serait plus important que le travail de compat ascendante (compat binaire à l'instant t, t -1, t +1 - qui est tout aussi impossible) ?
Car il est clair que tout les utilisateurs n'upgradent pas leur système au même moment. Ainsi l'objectif d'universalité ne serait toujours pas atteint.
- Le monde n'est pas i386. GD souhaite-t-il qu'à terme, les binaires Debian/sparc tournent sur Mdv/x86 ? ça n'a aucun sens. Cette compat ne peut exister qu'au niveau des sources.
- Même si toutes les distros à l'instant t étaient compatibles et utilisaient les mêmes logiciels, les mises à jour sécu sont gérées différement (backports ou upgrade de version, ...). À la première faille de sécu de firefox, par ex., les packages contenant les plugins deviendraient incomptibles entre les distros. La distribution des packages adéquat doit être gérée ... par les distributions !
- La LSB conçue comme un layer de compatibilité binaire (elle n'est pas que ça) est une illusion que dénonce d'ailleur un des plus éminents spécialistes du sujet, le mainteneur de la glibc: http://www.livejournal.com/users/udrepper/8511.html
En bref il nous dit: la compatibilité est possible seulement aun niveau des sources, LSB est fait par des amateurs incompétents.
- Il y a de nombreux projets de normalisation / standardisation qui ont pour vocation d'améliorer la compatibilité (au niveau des sources) ou les échanges entre les distros, entre les implémentations, et entre les libs/softs utilisés sous linux: POSIX, Freedesktop.org, Launchpad, Posixtestssuite, Tango, D-Bus, C89 ...
Pourquoi GD met-il l'accent sur le projet le plus improbable (la compat binaire) plutôt que d'affirmer publiquement son soutient à ces initiatives réalistes et pragmatiques ?
- Le respect de la LSB et le fait que les libs soient présentent dans la même version entre plusieurs distribution ne suffit pas à assurer la compat des packages. Il y a aussi des choix technologiques qui sont important, et dont l'intégration n'est possible qu'en compilant ad hoc à partir des sources: type de serveur de son utilisé (arts ? esd ? jack ?), présence ou non de certaines libs et outil pour des raisons politique souveraines à chaque distro (mp3, divx, SELinux, quicktime, ...), façon de privilégier, pour tel logiciel, les fonctionalités ou la maturité (eg. choix d'apache1 ou apache2), emplacement et droit (et uid/gid propriétaires) sur les repertoires/fichiers ...
Celà introduit suffisament de différences pour qu'un package lambda présente toujours un risque d'incompatibilité, entre deux distros, légère ou pas.
- Si la compatibilité à 100% est impossible, est-il vraiment sérieux, pour quelqu'un qui prend la qualité logicielle au sérieux (mais est-ce le cas de Gaël Duval ?) d'en faire part ? Est-ce que Mandriva peut se permettre de recommander à ses utilisateurs d'essayer les packages Red Hat (ou l'inverse) ? dans ce cas, à quoi bon chippoter sur la compat binaire ?
- Si le but implicite est de permettre l'échange de packages entre les distros, on peut se demander si cet objectif est vraiment judicieux: avec plus de 10 000 packages, les developpeurs de distros semblent ne pas avoir trop de mal à faire des binaires pour leurs plateformes. Quand ils font oublis (ou autre), la communauté le fait à leur place et s'en sort très bien aussi (cf. plf, debian-marillat, etc.). Au final l'utilisateur trouvera presque toujours un package sur mesure. Sauf pb de brevet ou logiciel propriétaire (mais cf. ci-dessous).
Mais surtout: l'importance du travail, d'un developpeur de distribution, la vrai valeur ajoutée de ce travail, ce n'est pas vraiment qu'il fasse un binaire packagé (un utilisateur moyen peut le faire), c'est qu'il ai bien pris le temps de le tester, de le polir, de l'intégrer proprement, de vérifier s'il ne pose pas de soucis / conflits avec les autres logiciels de la distro, que son update ne pose pas de pb etc.
Vouloir se fier à la compatibilité binaire, c'est vouloir éviter le premier pas, la compilation (qui permet de vérifier bien des choses) de ce travail de qualité logicielle, et probablement les pas suivants aussi...
- Si le but implicite de ce machin est de permettre aux ISV / logiciels propriétaires de tourner sur toutes les distribs sans avoir à compiler sur chaque plateforme, on peut supposer que son interet pour les ISV soit de ne pas essayer / tester / faire du qa sur les divers distribs. Le résultat serait bien sûr des logiciels insuffisament stable.
Preuve ? si vous étes utilisateurs de Mdv (qui est très compatible RH nous dit GD) et que vous avez le choix entre un rpm Mdv et un rpm RH, vous choisissez lequel ? le Mdv, parceque la stabilité de l'autre vous inquietera (Red Hat n'ayant pas testé sur votre plateforme).
On peut aussi trouver inadéquat que les distros fassent un tel sacrifice (celui de devenir uniformes) et déploient de tels effort seulement pour faire tourner du logiciel propriétaire dans des conditions n'assurant pas sa pleine stabilité/compatibilité ...
- GD ne nous explique pas vraiment quel est son problème avec la « compatibilité par les sources », en quoi c'est insuffisant. Pour l'échange entre distros ? (mais on voit ci-dessus que l'alternarive "binaire" est un objectif impossible si on est rigoureux, là ou l'échange par les sources est faisable et finalement simple).
Pour les logiciels propriétaires ? cf. ci-dessus: les ISV qui veulent de la stabilité garantie ne supporteront jamais que les distros sur lesquels ils ont bcp testé (oracle -> RHEL & Suse), ou compileront et testeront sur plein de distros (skype, opera ...), ou fourniront un système de compilation automatisé sur mesure (nvidia). Bref, les ISV comme les LL ont des solutions pour gérer l'incompat (binaire et technologique), elles passent toute par la compilation sur la plateforme cible, et ça fonctionne bien comme ça.
Le propos de Gaël Duval n'aide pas à établir le sérieux de son produit, et il est dommage que linuxfr s'en soit l'echo.
C'est exactement ce que j'ai pensé à la lecture de cette « faq ».
En fait de de "frequently asked questions", on voit dans les threads ci-dessus que celles qui se posent pour les utilisateurs (ou pas) de Mandriva ne sont pas les mêmes que celles qui se posent à Ubuntu ; et que GD ne répond pas aux bonnes questions.
Je ne comprend vraiment pas pourquoi GD à voulu lancer ce troll sur Ubuntu (assorti d'inepties sur la compat binaire). Ni pourquoi Jarillon s'est empréssé de le lui faire traduire et proposer une dépêche ici (enfin, j'ignorai qu'il était un commercial ...).
Quant à la réputation, elle me fait bien marrer, on critique à la fois Mandriva pour sortir des logiciels trop vieux et trop récents.
Non, on la critique parce qu'elle ne sait pas sortir des produits stables (que les logiciels utilisés soient vieux ou récents, ce qui importe c'est qu'ils soient stabilités dans la distro).
mais quelle est le but de ces fondations
Et bien de diriger le developpement des projets de façon communautaire.
Quand Ubuntu décide de tout modifier sur le fonctionnement de nautilus, tu avais vu des discussions préliminaires sur la liste de développement ?
2- "Quand Ubuntu décide [...]" : Ubuntu, c'est nous. C'est qui veut bien participer. Tu sent un peu la différence avec le monde mdk ? j'ai l'impression que j'ai du mal à me faire comprendre parceque tout celà vous est trop étranger (à Cooker et toi)...
3- "modifier un peu le mode spatial" != "tout modifier" (ce qu'ils font en upstream, btw), et je parlai des décisions importantes, ça c'est du détail.
Moins fermé que Ubuntu/Canonical visiblement, car au moins, à ma connaissance, aucun outil Mandriva n'est pas libre.
Troll de bas étage. Tu parle bien sûr de lauchpad: il s'agit encore d'un service web en cours de developpement (qui sera releasé, et certainement libre). Celà étant posé, tu a les sources de tout le site web de Mandriva ? (ou partant, du site kernel.org, du site de osdl, etc etc).
Par contre Mdk s'est bien distinguée (avec Suse, qui ne fait généralement pas mieux sauf en termes de stabilité) pour être l'une des deux seules distros à accépter de signer des accords avec Intel pour la distributions de firmwares binaires, sabotant du même coup les appels au boycots et les pourparlers en cours dans les autres distros.
Donc oui, Mdk distribue des produits pas libre (pas Ubuntu), et oui, l'attitude "on fait une distrib payante pour ceux qui veulent payer" est néfaste aux utilisateurs de LL.
la plupart des critiques que j'avais émises [...]
Ah oui, à peut près ouvert comme Microsoft quoi. Ils ont aussi ouvert des wikis, des blogs etc. Ils sont aussi "à l'écoute des utilisateurs"...
Prise de décision: choix du kernel, de ses patches, des versions des logiciels, des axes de developpement etc.
Je n'ai nullement dit qu'ils n'existaient pas. Je dirait qu'ils sont décoratifs. Ce n'est pas le processus de décision chez mdk (comparez le avec Debian par exemple).
Et c'est incomparable avec l'effort fait par Ubuntu pour mutualiser les efforts de packaging, localisation et stabilisation.
Ceci dit, je rappelle que la question principale soulevée par GD et que je traitais ici c'est celle de la compatiblité binaire: c'est un chimère, et GD à tort de se moquer du travail fait pour obtenir une meilleure échange au niveau des sources/patches etc.
J'ajoutais simplement que l'ironie de GD témoigne d'un certain malaise ...
Son point sur « la compatibilité binaire à un instant t » est complétement fumeux et hypocrite: il sert à détourner les questions sur les faiblesses du modèle de Mandriva.
À un « instant t », on a une Debian-stable et une RHEL qui utilisent des versions longuement testées et validées des divers libs, et une Mandriva qui utilise la version bleeding edge de tout ce qui passe (sa réputation de distribution instable ne sort pas des choux d'ailleur).
Donc à cet « instant t », pour des choix de police de chaque distribution, on a une grande disparité. Les packages binaires dynamiques ne seront jamais pleinement compatibles avec toutes les principales distros de cet "instant t". La preuve est que les 12000 pkgs Mandriva ne sont pas ceux faits par Red Hat ou autre (et ils ne les ont pas repackagé pour le plaisir ...): lorsqu'on pense que la stabilité est importante, on ne se contentera pas d'un "ce pkg binaire doit à peut près marcher parceque je suis compatible LSB ou Red Hat".
Ainsi l'approche de Shuttleworth est pragmatique: faisont en sorte que tout le travail de polissage des applications qui précède le packaging soit partagé, celà augmentera l'efficacité et la qualité de toutes les distributions qui jouent le jeu. Celà améliorera la possibilité de compilation portage sur les autres distribs au temps t, t-1, t+1...
Le packaging final et la distribution des binaires est une fausse question.
Ce dont parle Shuttleworth lorsqu'il prone « l'échange au niveau des sources » ce n'est pas seulement, et Duval le sait même s'il fait semblant de ne pas comprendre, l'échange des logiciels, mais surtout l'échange des informations, connaissance des problèmes/incompatibilités, patches, bugs détéctés, localisations, ... d'où l'important travail de Canonical sur Lauchpad et Bazaar, son travail sur la transparence, l'utilisation systématique de wikis, l'accès temps réel ouvert à tous aux dépôts bazaar et aux traductions, la fondation indépendante Ubuntu. Ou encore le travail de Red Hat pour faire une fondation Fedora, au modèle de developpement ouvert, le modèle 100% ouvert de Debian etc.
Ce type d'échanges est un point sur lequel Mandriva est très criticable, avec son modèle de développement fermé, sa base de connaissance "à niveaux" (developpeurs, membres du club etc.), son modèle de compagnie fermée (les utilisateurs et devs indépendants ont du se battre pour se frayer un passage), prises de décisions 100% en interne ...
C'est une utilisation déplacée des benchmarks en question (qui sont, au passage, franchement orientés), en tout cas pas pertinente pour contester le fait que que java rende openoffice encore plus lent et lourd:
1 - Ces benchmarks n'évaluent pas le qualificatif de "lourd". Java est lourd (occupe beaucoup plus de mémoire qu'un prog équivalent en C), conteste-tu celà ?. Cette lourdeur / consomation de mémoire affecte les performances sur une machine pesronelle, surtout lorsqu'on a une grosse appli à coté (comme ooffice), qui augmente encore les chances de swapper.
2 - Ces benchmarks n'évaluent pas le temps de chargement (qui comptent beaucoup pour l'utilisateur de suites bureautiques !), seulement le temps de calcul sur des opérations très mathématiques. Et même l'auteur (pourtant très partis pris) en convient dans l'article "Java program startup is slow" .
Ce qui n'est pas un gros pb sur un serveur, où on re-lance rarement les applis, où l'on a généralement assez de mémoire pour tout charger (plugins etc) dès le départ, et où l'on ne charge pas d'énomes toolkits graphiques à la awt/swt/swing; sur un desktop, en revanche, c'est fatal.
gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage
Par contre la rapidité d'execution des pgms compilés avec gcj est catastrophique ...
On a Qtopia/Opie, Gpe, Maemo, etc. pour les environnements graphiques finaux, OpenEmbedded, scratchbox, buildroot, embedix ... pour les environements de developpement & toolchains, et c'est sans parler des solutions commerciales, qui se mettent à fleurir (chez metrowerks, lynuxworks, montavista, windriver ...). Au final on a souvent beaucoup (pour ne pas dire trop) de choix concernant ce qu'on va mettre (et comment le mettre) dans le ventre de son périphérique.
Evidement, les constructeurs de telephones (et les opérateurs) préfèrent pousser l'API j2me parce qu'elle leur permet de changer facilement ce qu'il y a en dessous...
* disparition de gnome-panel (bug connu, voir les release notes, vite réglé)
* souris USB non reconnue (vite réglé aussi)
* le driver de ma carte gfx dans xorg.conf est revenu à nv (un coup de vim et on n'en parle plus)
* gdm n'ouvre plus les sessions dans la locale choisie [testé avec gnome, xfce, icewm] (j'utilise l'anglais par habitude mais ma femme qui préfère les environnements en français est moyennement contente). par contre, impossible de régler cela. il manque un outil pour gérer les locales installées et celle par défaut.
Et pour ce qui est de la disponibilité du driver, s'il n'est présent de base que dans les versions commerciales, l'installation est quand même assez simple (si c'est trop compliquer, il suffit d'acheter une version commerciale)
Disont que leur modèle propriétaire fragilise un peu l'ensemble du "desktop sous Linux": nvidia ou ati peuvent décider de ne plus supporter Linux, ou d'imposer leurs conditions. L'interface du noyau ou de x.org pourraient changer, et les drivers rester inutilisables avec ces nouvelles api pendant longtemps (c'est arrivé plusieurs fois avec nvidia et surtout ati). Ils pourraient ne pas corriger (ou prendre beaucoup de temps pour corriger) d'éventuelles failles de sécu. Ils pourraient forcer la mise à jour (l'achat) de matériels plus récents en ne maintenant pas le driver pour leurs anciens modèles. etc.
Mais par contre, devrait-on sous ce pretexte ne pas évoluer du tout
On est d'accord. La question soulevée par l'article c'est plutot de determiner comment et vers où évoluer.
Mon propos initial c'était qu'un bureau en 3D, c'est très bien, mais quand même pas si follement inovant que ce qu'X11 à pu faire auparavant (archi client-serveur, multi-utilisateurs etc.). Et que ça ne mérite peut-être pas de sacrifier aveuglément la portabilité et le support fonctionel du matériel ancien, ni d'augmenter notre dépendance aux drivers propriétaires. D'autant qu'il y a déja un support optionel pour l'accélération OpenGL dans x.org (mais à ce stade, il reste facultatif).
Avec une organisation correcte, ne pourrait-il pas simplement être possible d'ajouter des fonctionnalités, améliorer X tout en permettant de ne pas activer ces fonctions pour les archis / cartes graphiques ne les supportant pas ?
Justement, concernant l'utilisation d'OpenGL, Smirl souhaiterai qu'il n'y ai qu'un seul moteur sous-jacent, cf. sa conclusion ; ça demanderait d'ailleur un énorme travail d'adaptation (dans x.org et dans mesa) pour émuler ça avec les vieilles cartes graphiques. C'est ce que lui ont fait remarquer ses camarades de x.org, dans l'ensemble (heureusement) pas emballés par son troll.
Au contraire, seul les modules d'adaptations seront à faire.
Aussi (et surtout) l'adaptation de tout les logiciels qui utilisent ces fonctionalités en pensant "the world is Linux on i386".
Autre détail: si celui qui conçoit ces hooks ne connait que Linux, il est probable que leurs interfaces ne seront adaptées qu'aux sous systèmes de Linux.
Les developpeurs *BSD s'inquietent (surtout depuis le decrochage d'XFree86 vers x.org) de voir x.org prendre une tournure de plus en plus linuxentrique.
Témoin cette erreur (plusieurs fois répétée dans l'article) : FreeBSD possède bien un support framebuffer fonctionnel, Mr. Smirl.
Les developpeurs *BSD ont implémenté la séparation des privilèges en userspace dans x.org (portable), mais Smirl semble l'ignorer et préconise l'utilisation de modules noyaux pour faire tourner le code privilégié: une toute autre philosophie.
Smirl semble souhaiter un accroissement des dépendances aux fonctionalités spécifiques à GNU/Linux et ce n'est pas très encourageant, surtout s'il n'est pas en mesure de bien les identifier.
On s'éloigne de l'époque ou X11 était développé par des pionniers ayant une grande culture des systèmes Unix, inventant un système très innovant (totalement orienté réseau, portable, multiutilisateurs: c'était une revolution, à la façon Unix)... Et vient l'époque des bricolages rapides pour ressembler à Windows au plus vite. Que du bon.
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 2.
Que j'ai tort ou raison, la faible représentation des devs mdk dans ces projets cruciaux fait que ces priorités ne changeront pas (au-delà de LSB).
Ceux qui font évoluer les choses ne sont pas les commercials qui disent leur opinion sur leur page perso, mais les developpeurs (si tu veut vraiment de la compat binaire, au lieu de raler contre les choix devs, tu n'a qu'à y travailler).
[^] # Re: Mauvaise communication
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 1.
Oui, mais il est assez insultant pour ses utilisateurs de qualifier l'engoument pour Ubuntu d' « effet de mode » ou de « hype ».
Puisque Ubuntu vise en partie le même public que Mandriva (le grand public / les utilisateurs novices), il me semble qu'il serait plus intelligent de la part de Gaël Duval de considérer qu'Ubuntu répond à des attentes de ce public, d'analyser objectivement les raisons de son succès (!= se contenter de l'attribuer à la "hype") pour améliorer son propre produit.
On (utilisateurs d'Ubuntu) s'evertue dans cette dépêche à expliquer ce qui nous a séduit chez Ubuntu ou ce qui nous a déplu dans l'image (ou la réalité, peu importe) de Mandriva. Et aucun Mandriviste pour en tirer parti. Dommage.
Je dirait qu'une des raisons du succès d'Ubuntu est l'impression -fondée ou illusoire- pour les utilisateurs d'être vraiment écoutés, d'être le noyau qui fait progresser la distribution: choix et décisions en fonctions de nos besoins effectifs, impression d'être partie prise et partie prenante dans le processus etc.
C'est que c'est ce qui nous a manqué chez Mandriva que nous avons finalement quitté: fondée ou illusoire, l'impression d'un mode de developpement opaque, corporate, d'une ironie présomptueuse des dirigeant comme celle de GD dans son texte, ambiguités sur le "club", les objectifs etc. Votre attitude n'arrange rien à cette image qui colle à mdv.
Il ne faut pas se contenter pas de dire à longueur de post "mdv est une distrib qui donne la parole aux users, une distrib basée sur la communauté contrairement à votre impression": il faudrait peut-être se demander pourquoi elle n'a pas cette image. Il faudrai peut-être se demander pourquoi les utilisateurs migrent par miliers chez Ubuntu (et nos commentaires devraient vous aider, non ?).
avait fait du logiciel propriétaire (tel Launchpad)
Oui sauf qu'on en parle pas de logiciel propriétaire pour un service (tu a les sources du site web de mandriva ou de red hat ? de google ?) et que ce service est simplement en phase initiale de developpement, que son code sera ouvert lorsque "releasé".
En attendant Launchpad fait mouche et crée une effervecence dans la communauté des utilisateurs. Ce serait un peu dommage de ne pas s'en rendre compte, ne pas se demander si ça répond à un besoin réel.
par une entreprise commerciale dont l'existence repose sur le mécénat. Pour l'instant, on ne sait pas ce que Canonical vaudrait sans les fonds de Shuttleworth.
Canonical est lancé avec les fonds de Shuttleworth et c'est normal. Connais tu une entreprise qui soit lancée sans capital ?
Par contre Ubuntu n'est pas une entreprise commerciale, et ce qui fait son vrai capital, selon moi, c'est une communautré d'utilisateurs engagés et enthousiastes. Finallement ce sont eux qui font l'effervécence et la "hype" dont parle Duval et qui fait défaut à Mdv.
Tout ceci à de quoi intriguer. Il est normal que des gens comme Duval disent ce qu'ils en pensent.
Bah oui, et ce qu'en pense Duval, visiblement, c'est qu'Ubuntu est un pur effet de hype, de poudre aux yeux orientée "choix de la couleur de fond d'écran et idolatrie des spationautes". On en déduira que selon lui les utilisateurs d'Ubuntu sont des cons dupés par le marketing qui ne savent pas juger d'un bon produit. Très bien, mais j'espère qu'il ne souhaite pas faire venir les utilisateurs chez lui avec un tel discours... vu le problème d'image (fondé ou pas) de mdv qui est apparu dans les autres commentaires, son attitude est suicidaire.
Comme disait un commentaire plus haut, la FAQ de Shuttleworth est vraiment une FAQ, elle répond vraiment aux questions qui se posaient fréquement dans la communauté Ubuntu (et Debian). C'est tout à son honneur d'avoir su les entendre pour y répondre précisément. Ça fait parti des choses qui nous donnent l'impression d'être entendus.
Le texte de Gaël Duval parrait en revanche lancé de sa tour d'ivoire, et ne répond pas aux questions que les utilisateurs se posent sur mandriva (eg. la couleur du fond d'écran n'est une question vraiment vive que chez ubuntu) mais se contente de "dire ce que Duval en pense" (d'Ubuntu) ou de se moquer légèrement des Ubuntistes. Je trouve que c'est une super mauvaise idée d'en avoir fait une dépêche de première page On approche les 300 commentaires, signe caractérisé d'une discussion stérile (aka, "un troll").
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 1.
Oui ubuntu est jeune est c'est en train de se mettre en place. Maintenant c'est ok, il y a PLF.
> avec blender (je veux la dernière version) --> ~/.local/blender/
Ça c'est une autre question (les paths d'installation). Tu peut bien l'installer system-wide (/usr ou /usr/local) comme le ferait d'ailleur un package venant d'une autre distrib (si tu avait la fameuse "compatibilité binaire"). Mais tu hésite à le faire pour ne pas pourir ta distro, ce que je comprend bien. Mais tu aurait autant hésité (pour les mêmes raisons) avec un package binaire "alien".
Dans tout les cas, vouloir plus de compatiblité binaire c'est incompatible avec le fait d'utiliser en permanence les versions bleeding edge des logiciels (puisqu'il faut un minimum de stabilité des api et abi).
> et lorsque c'est gnome ou kde qui manque, peut on envisager de le compiler dans /usr/local ?
Bin oui, c'est ce que font FreeBSD et OpenBSD par exemple.
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 0.
> Ca te perturberait si je te disais qu'il y en a ? Genre Arnaldo Carvalho de Melo ?
Wow, avec ça ils sont super bien parés pour faire la loi sur LKML. Red Hat et Suse n'ont qu'à bien se tenir !
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 5.
Hein ? j'élude quoi ?
J'explique (en argumentant) que la compatibilité binaire entre les diverses distros demanderai un travail trop important pour qu'on puisse le faire, donnerai un résultat insuffisant et instable, et ne serait pas utile car il existe des solutions (au problème nommé: faire tourner l'appli x version y sur la plateforme z) qui marchent très bien (utiliser un package standard, ou installer par les sources, ou récupérer le package non officiel d'un autre utilisateur qui l'a construit).
> Il faut que les utilisateurs puissent installer rapidement et simplement des programmes depuis le web, depuis un CD-ROM.
Tout à fait, et c'est ce qu'ils font déjà. Tu utilise LFS ou quoi ?
> Maintenir plus de 10000 paquets est un travail fastidieux et inutile
OK alors on résume: si chaque paquet n'était packagé qu'une seule fois, il n'y aurait tout simplement qu'une seule distrib. Ça ne me semble vraiment pas souhaitable.
Parceque le fait de produire le binaire, c'est peanuts, c'est peut être 5% du temps passé sur la préparation du paquet (le tester, le mettre à l'épreuve, le documenter, ...). Faire le binaire + préparer le paquet (test, debug etc.) c'est bien le travail des distros. Autrement dit: polir, debugguer, améliorer les logiciels (et accessoirement les compiler et packager). S'il y a moins de personnes qu'ils le font, alors les logiciels seront moins bons (je parle des tests bien sûr, parceque la compilation/packaging, c'est maintenant totalement automatisé dans la plupart des cas).
Quand au "fastidieux et inutile", il faudra alors m'expliquer pourquoi un millier de developpeurs se pressent au portilion debian.
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 5.
Un détail: dans le monde windows (aka "propriétaire"), on réimplémente / réinvente la roue sans cesse (ou se linke statiquement lorsqu'on a acheté une lib). L'essentiel des API/libs partagées sont celles d'un seul fournisseur, microsoft. Des miliers de boites réécrivent les mêmes fonctionalités, en permanence.
Dans le LL on mutualise le travail jusqu'au sang ; on fait des libs par centaines. On réutilise tant qu'on peut. On partage les fonctionalités.
Et c'est pour ça qu'avec un nombre de developpeurs beaucoup plus restreint, on arrive à un résultat très satisfaisant.
La contrepartie, c'est qu'il peut y avoir un jeu de dépendances très complexes entres les logiciels. Mais on s'en est toujours bien sorti parceque ce jeu de dépendance est établi à la configuration/compilation, par les sources. C'est astucieux, ça marche bien, et l'aspect fastidieux de la chose est
Maintenant, dans ces mêmes conditions, on pourrait travailler à avoir une compatibilité binaire approximative. Mauvaise idée: les ressources pour arriver à ce résultat seraient considérables: bien au delà de nos moyens, et bien au-delà de l'effort pour arriver à ce résultat sous windows (où les dépendances sont généralement nulles); et dans tout les cas, "approximatif" n'est pas suffisant: pourquoi souhaiter un environement fragile lorsqu'on à déjà quelque chose de robuste ?
> Le fait de distribuer des binaires un minimum permutables entre les distros ça ne retire rien du tout à ce qu'il est possible de faire
Mais si. Ça prendrai un temps infini, pour un résultat toujours douteux. Tu pense que les developpeurs kde/gnome/kernel/glibc sont incompétents lorsqu'ils disent que ce n'est pas un objectif pertinent ? Personellement je suis plutot content qu'ils travaillent à améliorer leurs applis, pas à bidouiller sur les binaires.
Pourquoi tu rale ? tu devrait plutot faire ce que tu dit puisque c'est si facile...
> le même binaire d'OOo 1.1.5 il tourne sur un windows
Cet exemple tombe à point. Les types d'OOo ont (un peu à la manière des éditeurs de logiciels propriétaires sous win32) tout ré-écrit, même leur propre toolkit graphique. C'est un travail ENORME. Un travail nécéssaire à l'époque, il n'y avait pas d'autres choix.
Même chose pour firefox, qui intègre un maximum de libs redondantes avec le système dans les tarballs binaires: ils peuvent se le permettre car leurs ressources (support financier, nombre de devs, ...) sont énormes, et parcequ'à leurs début il a fallu faire ça (pas le choix). Et encore, il s'agit d'appli ayant finalement relativement peu d'interactions avec le reste du système.
Maintenant les choses on changé, et je suis heureux que les developpeurs n'aient pas que ça à foutre ...
Il faut arréter de réver: combien d'appli gnome ou kde en C/C++ connait tu qui soient compatibles entres les distros majeures ?
Le mode de developpement des logiciels propriétaires sous win32 n'est pas adapté aux logiciels sous Unix libre (btw, ne pas oublier les *BSD), et ce qui est pour eux un besoin impératif (la compat. binaire) est pour nous totalement accéssoire.
Je me répete, mais bon j'ai pas l'impression que tu ai lu: la preuve: les logiciels propriétaires sous *nix s'en sortent très bien avec *nos* méthodes. À l'heure des machines virtuelles sous qemu pour 0 euros, ils peuvnt tous se payer un parc de compilation & tests pour les distribs majeures, ou trouver d'autres solutions: skype, kqemu, opera, sun jdk, nvidia, vmware, intel c++, oracle...
> Ben voilà, et si c'était simplement ça à remettre en cause ? ne changer les API que sur des choses vraiment majeure,
Mais c'est évidement remis en cause (par eux même), ce n'est pas quelque chose qui est arrivé volontairement. Les developpeurs ne se sont pas dit: "hé, les gars, et si on s'amusait à péter toute la compatibilité binaire dans la branche stable". L'exemple était là pour illustrer le fait qu'il est très dur, même pour des developpeurs chevronnés. Dans la plupart des cas, une simple correction de bug entraine un changement dont ne peut pas mesurer toutes les conséquences (cf. les raisons de la sortie de php 4.4 par ex.).
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 2.
> C'est justement ça qu'il aimerait changer.
Vu la superbe représentation des devs Mandriva sur LKML, c'est sûr que les coups de gueule de Gaël Duval sur son blog vont faire changer les chose :)
> si tu prend la situation actuelle (qui est justement critiquée) pour montrer que ce n'est pas possible
Je dit que ce n'est ni possible, ni intéressant.
Et je dit bien que ce n'est pas possible : donc dans la situation actuelle et les situations futures.
> Pourquoi nous on ne le pourrait pas techniquement ? tu m'expliques ?
Bon sang, mais j'ai passé 1/2 heure à l'expliquer juste au-dessus !
> Si déjà, pour les architectures courantes (x86, amd64, mac) du grand public
Ah, mais si tu cherche un système pour pécé seulement, grand public (seulement), dont l'ABI ne change jamais afin de faire tourner des logiciels propriétaires closed source, mon vieux, c'est tout vu. Windows est adapté à tes besoins.
Les softs MS eux-mêmes ne supportent que 2 ou 3 versions de windows au plus (cf. le futur ie7, ou office 2003 etc.), et pourtant leur modèle closed source les forces à garder des tonnes d'immondices (comme le DOS) pour assurer une compatibilité ascendante.
> Notes aussi que mac a trouvé une bidouille infame
Oui, pour le format des binaires. Maintenant si on parle de la compatibilité ascendante chez Mac (et même en ne restant que sur la série des Mac OS X), tu verra que ce n'est pas ça du tout.
> Pourquoi ? sauf cas où la faille touche justement l'API utilisée par les plugins, c'est justement l'exemple type où la compatibilité binaire ne devrait pas être cassée. D'ailleurs pour le coup, là, ça marche assez bien.
Simpe: parce que les types de firefox cassent très régulièrement l'API, et font des updates groupées (incluant du refactoring, pas uniquement les patches sécus). Cf. par ex. la cata. 1.0.4 -> 1.0.5. Et après l'arrivée prochaine de 1.5, je doute qu'ils maintiennent 1.0.* bien longtemps ("upgradez les gars").
[^] # Re: Mauvaise communication
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 1.
[^] # Re: Compatibilite binaire
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 8.
- Il n'y a pas d' « instant t » pour les distributions: Debian met plusieurs années à sortir, Fedora et Ubuntu sortent tout les 6 mois, Mandriva tout les ans ... Or, pour mémoire, il suffit d'avoir seulement un kernel différent (il en sort un nouveau tout les 3 mois) pour ne plus être compatibles (les modules du kernel t+1 ne sont pas adaptés au kernel t).
Donc il est impossible d'avoir les mêmes versions des libs compilées avec le même compilateur, avec les mêmes patches, sur le même kernel, en même temps, et sur toutes les distros. À partir de là, la compatibilité binaire ne peut arriver que "par chance" ou "par hasard", comme dit Shutlleworth.
- Quand bien même il y aurai une « compatibilité binaire à l'instant t », en quoi celà serait plus important que le travail de compat ascendante (compat binaire à l'instant t, t -1, t +1 - qui est tout aussi impossible) ?
Car il est clair que tout les utilisateurs n'upgradent pas leur système au même moment. Ainsi l'objectif d'universalité ne serait toujours pas atteint.
- Le monde n'est pas i386. GD souhaite-t-il qu'à terme, les binaires Debian/sparc tournent sur Mdv/x86 ? ça n'a aucun sens. Cette compat ne peut exister qu'au niveau des sources.
- Même si toutes les distros à l'instant t étaient compatibles et utilisaient les mêmes logiciels, les mises à jour sécu sont gérées différement (backports ou upgrade de version, ...). À la première faille de sécu de firefox, par ex., les packages contenant les plugins deviendraient incomptibles entre les distros. La distribution des packages adéquat doit être gérée ... par les distributions !
- La LSB conçue comme un layer de compatibilité binaire (elle n'est pas que ça) est une illusion que dénonce d'ailleur un des plus éminents spécialistes du sujet, le mainteneur de la glibc: http://www.livejournal.com/users/udrepper/8511.html
En bref il nous dit: la compatibilité est possible seulement aun niveau des sources, LSB est fait par des amateurs incompétents.
- Il y a de nombreux projets de normalisation / standardisation qui ont pour vocation d'améliorer la compatibilité (au niveau des sources) ou les échanges entre les distros, entre les implémentations, et entre les libs/softs utilisés sous linux: POSIX, Freedesktop.org, Launchpad, Posixtestssuite, Tango, D-Bus, C89 ...
Pourquoi GD met-il l'accent sur le projet le plus improbable (la compat binaire) plutôt que d'affirmer publiquement son soutient à ces initiatives réalistes et pragmatiques ?
- Le respect de la LSB et le fait que les libs soient présentent dans la même version entre plusieurs distribution ne suffit pas à assurer la compat des packages. Il y a aussi des choix technologiques qui sont important, et dont l'intégration n'est possible qu'en compilant ad hoc à partir des sources: type de serveur de son utilisé (arts ? esd ? jack ?), présence ou non de certaines libs et outil pour des raisons politique souveraines à chaque distro (mp3, divx, SELinux, quicktime, ...), façon de privilégier, pour tel logiciel, les fonctionalités ou la maturité (eg. choix d'apache1 ou apache2), emplacement et droit (et uid/gid propriétaires) sur les repertoires/fichiers ...
Celà introduit suffisament de différences pour qu'un package lambda présente toujours un risque d'incompatibilité, entre deux distros, légère ou pas.
- Si la compatibilité à 100% est impossible, est-il vraiment sérieux, pour quelqu'un qui prend la qualité logicielle au sérieux (mais est-ce le cas de Gaël Duval ?) d'en faire part ? Est-ce que Mandriva peut se permettre de recommander à ses utilisateurs d'essayer les packages Red Hat (ou l'inverse) ? dans ce cas, à quoi bon chippoter sur la compat binaire ?
- Si le but implicite est de permettre l'échange de packages entre les distros, on peut se demander si cet objectif est vraiment judicieux: avec plus de 10 000 packages, les developpeurs de distros semblent ne pas avoir trop de mal à faire des binaires pour leurs plateformes. Quand ils font oublis (ou autre), la communauté le fait à leur place et s'en sort très bien aussi (cf. plf, debian-marillat, etc.). Au final l'utilisateur trouvera presque toujours un package sur mesure. Sauf pb de brevet ou logiciel propriétaire (mais cf. ci-dessous).
Mais surtout: l'importance du travail, d'un developpeur de distribution, la vrai valeur ajoutée de ce travail, ce n'est pas vraiment qu'il fasse un binaire packagé (un utilisateur moyen peut le faire), c'est qu'il ai bien pris le temps de le tester, de le polir, de l'intégrer proprement, de vérifier s'il ne pose pas de soucis / conflits avec les autres logiciels de la distro, que son update ne pose pas de pb etc.
Vouloir se fier à la compatibilité binaire, c'est vouloir éviter le premier pas, la compilation (qui permet de vérifier bien des choses) de ce travail de qualité logicielle, et probablement les pas suivants aussi...
- Si le but implicite de ce machin est de permettre aux ISV / logiciels propriétaires de tourner sur toutes les distribs sans avoir à compiler sur chaque plateforme, on peut supposer que son interet pour les ISV soit de ne pas essayer / tester / faire du qa sur les divers distribs. Le résultat serait bien sûr des logiciels insuffisament stable.
Preuve ? si vous étes utilisateurs de Mdv (qui est très compatible RH nous dit GD) et que vous avez le choix entre un rpm Mdv et un rpm RH, vous choisissez lequel ? le Mdv, parceque la stabilité de l'autre vous inquietera (Red Hat n'ayant pas testé sur votre plateforme).
On peut aussi trouver inadéquat que les distros fassent un tel sacrifice (celui de devenir uniformes) et déploient de tels effort seulement pour faire tourner du logiciel propriétaire dans des conditions n'assurant pas sa pleine stabilité/compatibilité ...
- GD ne nous explique pas vraiment quel est son problème avec la « compatibilité par les sources », en quoi c'est insuffisant. Pour l'échange entre distros ? (mais on voit ci-dessus que l'alternarive "binaire" est un objectif impossible si on est rigoureux, là ou l'échange par les sources est faisable et finalement simple).
Pour les logiciels propriétaires ? cf. ci-dessus: les ISV qui veulent de la stabilité garantie ne supporteront jamais que les distros sur lesquels ils ont bcp testé (oracle -> RHEL & Suse), ou compileront et testeront sur plein de distros (skype, opera ...), ou fourniront un système de compilation automatisé sur mesure (nvidia). Bref, les ISV comme les LL ont des solutions pour gérer l'incompat (binaire et technologique), elles passent toute par la compilation sur la plateforme cible, et ça fonctionne bien comme ça.
Le propos de Gaël Duval n'aide pas à établir le sérieux de son produit, et il est dommage que linuxfr s'en soit l'echo.
[^] # Re: Mauvaise communication
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 3.
C'est exactement ce que j'ai pensé à la lecture de cette « faq ».
En fait de de "frequently asked questions", on voit dans les threads ci-dessus que celles qui se posent pour les utilisateurs (ou pas) de Mandriva ne sont pas les mêmes que celles qui se posent à Ubuntu ; et que GD ne répond pas aux bonnes questions.
Je ne comprend vraiment pas pourquoi GD à voulu lancer ce troll sur Ubuntu (assorti d'inepties sur la compat binaire). Ni pourquoi Jarillon s'est empréssé de le lui faire traduire et proposer une dépêche ici (enfin, j'ignorai qu'il était un commercial ...).
[^] # Re: La différence est dans la communauté
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à -4.
[^] # Re: Hypocrisie de Gael Duval
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 1.
Non, on la critique parce qu'elle ne sait pas sortir des produits stables (que les logiciels utilisés soient vieux ou récents, ce qui importe c'est qu'ils soient stabilités dans la distro).
mais quelle est le but de ces fondations
Et bien de diriger le developpement des projets de façon communautaire.
Quand Ubuntu décide de tout modifier sur le fonctionnement de nautilus, tu avais vu des discussions préliminaires sur la liste de développement ?
1- oui, plein. par exemple :
https://bugzilla.ubuntu.com/show_bug.cgi?id=8516
https://bugzilla.ubuntu.com/show_bug.cgi?id=8548
http://www.ubuntuforums.org/showthread.php?t=23421
http://lists.ubuntu.com/archives/ubuntu-devel/2005-April/thr(...)
2- "Quand Ubuntu décide [...]" : Ubuntu, c'est nous. C'est qui veut bien participer. Tu sent un peu la différence avec le monde mdk ? j'ai l'impression que j'ai du mal à me faire comprendre parceque tout celà vous est trop étranger (à Cooker et toi)...
3- "modifier un peu le mode spatial" != "tout modifier" (ce qu'ils font en upstream, btw), et je parlai des décisions importantes, ça c'est du détail.
[^] # Re: Hypocrisie de Gael Duval
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à -3.
Troll de bas étage. Tu parle bien sûr de lauchpad: il s'agit encore d'un service web en cours de developpement (qui sera releasé, et certainement libre). Celà étant posé, tu a les sources de tout le site web de Mandriva ? (ou partant, du site kernel.org, du site de osdl, etc etc).
Par contre Mdk s'est bien distinguée (avec Suse, qui ne fait généralement pas mieux sauf en termes de stabilité) pour être l'une des deux seules distros à accépter de signer des accords avec Intel pour la distributions de firmwares binaires, sabotant du même coup les appels au boycots et les pourparlers en cours dans les autres distros.
Donc oui, Mdk distribue des produits pas libre (pas Ubuntu), et oui, l'attitude "on fait une distrib payante pour ceux qui veulent payer" est néfaste aux utilisateurs de LL.
la plupart des critiques que j'avais émises [...]
Ah oui, à peut près ouvert comme Microsoft quoi. Ils ont aussi ouvert des wikis, des blogs etc. Ils sont aussi "à l'écoute des utilisateurs"...
Prise de décision: choix du kernel, de ses patches, des versions des logiciels, des axes de developpement etc.
[^] # Re: Hypocrisie de Gael Duval
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 4.
Et c'est incomparable avec l'effort fait par Ubuntu pour mutualiser les efforts de packaging, localisation et stabilisation.
Ceci dit, je rappelle que la question principale soulevée par GD et que je traitais ici c'est celle de la compatiblité binaire: c'est un chimère, et GD à tort de se moquer du travail fait pour obtenir une meilleure échange au niveau des sources/patches etc.
J'ajoutais simplement que l'ironie de GD témoigne d'un certain malaise ...
[^] # Re: Hypocrisie de Gael Duval
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 2.
http://www.livejournal.com/users/udrepper/8511.html
# Hypocrisie de Gael Duval
Posté par benp . En réponse à la dépêche Gaël Duval répond à Mark Shuttleworth. Évalué à 3.
À un « instant t », on a une Debian-stable et une RHEL qui utilisent des versions longuement testées et validées des divers libs, et une Mandriva qui utilise la version bleeding edge de tout ce qui passe (sa réputation de distribution instable ne sort pas des choux d'ailleur).
Donc à cet « instant t », pour des choix de police de chaque distribution, on a une grande disparité. Les packages binaires dynamiques ne seront jamais pleinement compatibles avec toutes les principales distros de cet "instant t". La preuve est que les 12000 pkgs Mandriva ne sont pas ceux faits par Red Hat ou autre (et ils ne les ont pas repackagé pour le plaisir ...): lorsqu'on pense que la stabilité est importante, on ne se contentera pas d'un "ce pkg binaire doit à peut près marcher parceque je suis compatible LSB ou Red Hat".
Ainsi l'approche de Shuttleworth est pragmatique: faisont en sorte que tout le travail de polissage des applications qui précède le packaging soit partagé, celà augmentera l'efficacité et la qualité de toutes les distributions qui jouent le jeu. Celà améliorera la possibilité de compilation portage sur les autres distribs au temps t, t-1, t+1...
Le packaging final et la distribution des binaires est une fausse question.
Ce dont parle Shuttleworth lorsqu'il prone « l'échange au niveau des sources » ce n'est pas seulement, et Duval le sait même s'il fait semblant de ne pas comprendre, l'échange des logiciels, mais surtout l'échange des informations, connaissance des problèmes/incompatibilités, patches, bugs détéctés, localisations, ... d'où l'important travail de Canonical sur Lauchpad et Bazaar, son travail sur la transparence, l'utilisation systématique de wikis, l'accès temps réel ouvert à tous aux dépôts bazaar et aux traductions, la fondation indépendante Ubuntu. Ou encore le travail de Red Hat pour faire une fondation Fedora, au modèle de developpement ouvert, le modèle 100% ouvert de Debian etc.
Ce type d'échanges est un point sur lequel Mandriva est très criticable, avec son modèle de développement fermé, sa base de connaissance "à niveaux" (developpeurs, membres du club etc.), son modèle de compagnie fermée (les utilisateurs et devs indépendants ont du se battre pour se frayer un passage), prises de décisions 100% en interne ...
[^] # Re: Il manque des trucs tout de même
Posté par benp . En réponse à la dépêche OpenOffice 2.0. Évalué à 9.
C'est une utilisation déplacée des benchmarks en question (qui sont, au passage, franchement orientés), en tout cas pas pertinente pour contester le fait que que java rende openoffice encore plus lent et lourd:
1 - Ces benchmarks n'évaluent pas le qualificatif de "lourd". Java est lourd (occupe beaucoup plus de mémoire qu'un prog équivalent en C), conteste-tu celà ?. Cette lourdeur / consomation de mémoire affecte les performances sur une machine pesronelle, surtout lorsqu'on a une grosse appli à coté (comme ooffice), qui augmente encore les chances de swapper.
2 - Ces benchmarks n'évaluent pas le temps de chargement (qui comptent beaucoup pour l'utilisateur de suites bureautiques !), seulement le temps de calcul sur des opérations très mathématiques. Et même l'auteur (pourtant très partis pris) en convient dans l'article "Java program startup is slow" .
Ce qui n'est pas un gros pb sur un serveur, où on re-lance rarement les applis, où l'on a généralement assez de mémoire pour tout charger (plugins etc) dès le départ, et où l'on ne charge pas d'énomes toolkits graphiques à la awt/swt/swing; sur un desktop, en revanche, c'est fatal.
gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage
Par contre la rapidité d'execution des pgms compilés avec gcj est catastrophique ...
[^] # Re: periphériques ouverts ?
Posté par benp . En réponse à la dépêche Formation libre sur Linux embarqué: un an après. Évalué à 3.
On a Qtopia/Opie, Gpe, Maemo, etc. pour les environnements graphiques finaux, OpenEmbedded, scratchbox, buildroot, embedix ... pour les environements de developpement & toolchains, et c'est sans parler des solutions commerciales, qui se mettent à fleurir (chez metrowerks, lynuxworks, montavista, windriver ...). Au final on a souvent beaucoup (pour ne pas dire trop) de choix concernant ce qu'on va mettre (et comment le mettre) dans le ventre de son périphérique.
Evidement, les constructeurs de telephones (et les opérateurs) préfèrent pousser l'API j2me parce qu'elle leur permet de changer facilement ce qu'il y a en dessous...
[^] # Re: résultat de la màj
Posté par benp . En réponse à la dépêche La distribution Mandriva GNU/Linux est prête pour 2006. Évalué à -2.
Faut pas être exigeant !
# Oui mais
Posté par benp . En réponse à la dépêche OpenBSD fête ses 10 ans !. Évalué à -10.
[^] # Re: x.org et GNU/Linux
Posté par benp . En réponse à la dépêche Le point sur le traitement graphique sous Linux. Évalué à 5.
Disont que leur modèle propriétaire fragilise un peu l'ensemble du "desktop sous Linux": nvidia ou ati peuvent décider de ne plus supporter Linux, ou d'imposer leurs conditions. L'interface du noyau ou de x.org pourraient changer, et les drivers rester inutilisables avec ces nouvelles api pendant longtemps (c'est arrivé plusieurs fois avec nvidia et surtout ati). Ils pourraient ne pas corriger (ou prendre beaucoup de temps pour corriger) d'éventuelles failles de sécu. Ils pourraient forcer la mise à jour (l'achat) de matériels plus récents en ne maintenant pas le driver pour leurs anciens modèles. etc.
Mais par contre, devrait-on sous ce pretexte ne pas évoluer du tout
On est d'accord. La question soulevée par l'article c'est plutot de determiner comment et vers où évoluer.
Mon propos initial c'était qu'un bureau en 3D, c'est très bien, mais quand même pas si follement inovant que ce qu'X11 à pu faire auparavant (archi client-serveur, multi-utilisateurs etc.). Et que ça ne mérite peut-être pas de sacrifier aveuglément la portabilité et le support fonctionel du matériel ancien, ni d'augmenter notre dépendance aux drivers propriétaires. D'autant qu'il y a déja un support optionel pour l'accélération OpenGL dans x.org (mais à ce stade, il reste facultatif).
Avec une organisation correcte, ne pourrait-il pas simplement être possible d'ajouter des fonctionnalités, améliorer X tout en permettant de ne pas activer ces fonctions pour les archis / cartes graphiques ne les supportant pas ?
Justement, concernant l'utilisation d'OpenGL, Smirl souhaiterai qu'il n'y ai qu'un seul moteur sous-jacent, cf. sa conclusion ; ça demanderait d'ailleur un énorme travail d'adaptation (dans x.org et dans mesa) pour émuler ça avec les vieilles cartes graphiques. C'est ce que lui ont fait remarquer ses camarades de x.org, dans l'ensemble (heureusement) pas emballés par son troll.
[^] # Re: x.org et GNU/Linux
Posté par benp . En réponse à la dépêche Le point sur le traitement graphique sous Linux. Évalué à 2.
Aussi (et surtout) l'adaptation de tout les logiciels qui utilisent ces fonctionalités en pensant "the world is Linux on i386".
Autre détail: si celui qui conçoit ces hooks ne connait que Linux, il est probable que leurs interfaces ne seront adaptées qu'aux sous systèmes de Linux.
# x.org et GNU/Linux
Posté par benp . En réponse à la dépêche Le point sur le traitement graphique sous Linux. Évalué à 10.
Témoin cette erreur (plusieurs fois répétée dans l'article) : FreeBSD possède bien un support framebuffer fonctionnel, Mr. Smirl.
Les developpeurs *BSD ont implémenté la séparation des privilèges en userspace dans x.org (portable), mais Smirl semble l'ignorer et préconise l'utilisation de modules noyaux pour faire tourner le code privilégié: une toute autre philosophie.
Smirl semble souhaiter un accroissement des dépendances aux fonctionalités spécifiques à GNU/Linux et ce n'est pas très encourageant, surtout s'il n'est pas en mesure de bien les identifier.
On s'éloigne de l'époque ou X11 était développé par des pionniers ayant une grande culture des systèmes Unix, inventant un système très innovant (totalement orienté réseau, portable, multiutilisateurs: c'était une revolution, à la façon Unix)... Et vient l'époque des bricolages rapides pour ressembler à Windows au plus vite. Que du bon.
# ... et le Venezuela
Posté par benp . En réponse à la dépêche Le Pérou souhaite l'autonomie de ses choix informatiques. Évalué à 2.
Histoire de maintenir la liste à jour, au cas où d'autres seraient intéressés.
# CSV
Posté par benp . En réponse à la dépêche MySQL 5.0 : Release Candidate 1. Évalué à -2.