clearstream a écrit 451 commentaires

> Dois-je en conclure que fedora distribue des logiciels non-free ?

Ce n'est pas Debian qui définit ce qui est libre ou non.
Si vraiment Debian était le chevalier blanc du logiciel libre, il n'y aurait pas de section "non-free" avec des choses sans codes sources, etc...

> latex2html est considéré comme non-free par Debian et est distribué dans fedora.

Voilà la licence :
http://www-texdev.ics.mq.edu.au/l2h/docs/manual/node5_ct.htm(...)
Je pense que c'est cette partie qui ne plait pas à Debian :

Use and copying of this software and the preparation of derivative works based on this software are permitted, so long as the following conditions are met:
* [...]
* No fees or compensation are charged for use, copies, or access to this software. You may charge a nominal distribution fee for the physical act of transferring a copy, but you may not charge for the program itself.
* [...]

C'est grave docteur ?

> Parce que quand on prend la definition de Debian (DFSG), la GFDL n'est pas libre,

Et la GPL n'est pas libre car l'utilisateur ne peut pas la modifier. Ok, Ok, Ok....
Et qu'en pense la FSF ?
Et qu'en pense RMS ?
Ce n'est pas Debian qui défini ce qui est libre ou non.

> Si le terme n'est pas defini, je ne vois pas comment on peut pretendre le respecter.

Fais comme ça :
- Prend le logiciel le plus "non-libre" de Fedora, et à partir de ce point, c'est libre pour Fedora.

Trouves un programme non libre (au sens de la FSF) dans Fedora (Core et Extras).
Des programmes non libre dans Debian, ça se trouve facilement.

Pour info :
Les sources de FC5 :
http://fr2.rpmfind.net/linux/fedora/core/5/source/SRPMS/
Les sources des mises à jours :
http://fr2.rpmfind.net/linux/fedora/core/updates/5/SRPMS/
Les sources de Fedora Extras 5 :
http://fr2.rpmfind.net/linux/fedora/extras/5/SRPMS/

Tu peux aussi regarder les binaires, ça ne change rien. Tout paquet rpm installable (hors d'une arborescence de build) a un paquet src.rpm.

> Si le terme n'est pas defini

http://www.fsf.org/

> sous GPL, sans la respecter (pas de source)

C'est un poil plus compliqué. Lorsque tu as une image png, tu estimes qu'il faut les sources ? C'est pourtant bien du binaire et il faut un programme pour l'interpréter et le modifier. Donc ce n'est manifestement pas lisible.
Je sais que la GPL est néanmoins assez claire sur ce point.

Le problème du firmware, est qu'on ne sait pas ce que c'est ET on ne sait pas ce que ça fait ! On constate seulement que c'est necessaire pour que le périphérique fonctionne.
C'est peut-être des sources en klingon, c'est peut-être un mot de passe pour déverrouiller la carte, c'est peut-être une image, etc...

Quel est le rôle de Linux ? C'est un firmware qui s'installe sur des périphériques ? Non. C'est un OS qui utilise des périphériques qui ont une tâche bien précises. La fonction "firmware de périphérique" ne fait pas partie des fonctions de Linux. Tu ne peux pas dire : "je veux les sources de cette fonction, car cette fonction est prise en charge par Linux, et car Linux est GPL".

> Renseigne-toi un peu : un satellite server, j'en ai un dans notre labo au taf', red hat le vend

Certe. Mais il y a quoi de propriétaire sur ta bécane ?
Fais un "rpm -q -i [paquet]".
Si j'ai dit une connerie, je t'applaudirai des deux si tu rétablis la vérité. Mais là je ne comprend pas où tu veux en venir.
T'es bien placer pour vérifier ce qu'il en est des licences côté client pour satellite server. Fais nous en profiter.
Je n'ai pas de satellite server.

> couplé à Oracle et ce n'est pas une licence libre que j'ai reçue pour le satellite

T'es sûr qu'Oracle est obligatoire ? Ce ne serait pas ton boss qui l'a imposé ?

> D'autre part, si tu me trouves un accès aux remontées d'infos à la hcl de red hat (hardware compatibility list et son bugzilla associé), cela m'intéresse.

Je ne comprend pas bien.
Pour info (j'image que c'est inutile) :
https://hardware.redhat.com/

Pour bugzilla, c'est ici :
https://bugzilla.redhat.com/
Attention, il n'y a que les bugs saisis directement par l'utilisateur, pas via hot-line ou équivalent. Mais si tu insistes pour que ton bug soit public, je ne vois pas pourquoi il ne le fairait pas.

En général Red Hat est assez porté sur la confidencialité pour les clients payants. C'est comme ça depuis bien longtemps (depuis toujours ?).
Notes que parmis les boîtes qui font du support payant (plus que seulement fournir des mises à jours), presque tout le monde fait comme Red Hat. C'est "con", mais le client l'exige.

> > "Mais il faut pondérer un peu."

> Non, il ne faut pas.

Au-lieu de pondérer, disons qu'il convient de bien en analyser les conséquences. C'est beaucoup moins grave que la propagation de skype par exemple.

> je ne vois pas de raison de ne pas reprocher à Red Hat ses services basés sur des logiciels proprio.

Notons qu'on ne sait pas si ce sont des logiciels proprios ! Mais je t'accord le raccourcis.

Plus haut j'ai dit :
- "Le reproche est tout à fait valable"

> pour Fedora effectivement (dans les grandes lignes... je ne vais pas ergoter sur les firmwares non libres en tableaux de nombres hexa trouvables dans tout kernel...).

Je trouve que Debian ergote beaucoup avec les firmwares. Si la carte a une ROM et que le firmware ne transite pas par Linux alors Debian est heureux alors que ça ne change RIEN de RIEN. Je préfère avoir le firmware dans Linux que de booter sous Windows pour charger le firmware puis faire un soft reset et passer sous Linux.

Ce qui serait cohérent si Debian n'aime pas les firmwares proprio, c'est que Debian vire tous les drivers pour cartes qui utilisent des firmwares non-libre (qu'il passe par Linux ou non). Là ça serait cohérent.

Tout ce que fait Debian, c'est pénaliser les gens qui ont acheter du hardware sans ROM (ce qui peut permettre de mettre un firmware libre si l'occasion se présente).

Autre chose, ces firmwares dans Linux sont sous GPL ! Certe, la GPL n'est pas totalement respectée (c'est un peu subjectif). Mais je préfère les voir sous GPL que sous je ne sais qu'elle licence proprio.
Le seul problème de ces firmwares est qu'ils ne sont pas "lisibles". Mais ils sont librement utilisables.

Puis pour le respect de la GPL, on peut déplacer les firmwares dans /lib/firmware. Je ne vois pas ce qui gagnera le libre mais on ne peut pas être contre.

> Un logiciel non-free dans debian n'est pas forcément un logiciel proprio.

Un logiciel non-free diffusé par debian est forcément un logiciel non-free !
Un logiciel diffusé par Fedora (et d'autres) est forcément un logiciel libre !

> c'est à dire qui ne correspondent pas à 100% aux critères définit par Debian.

Donc pourquoi ces critères s'il est si facile de les contourner et au sein même de Debian ?
Quel est la crédibilité de ces critères ?
Pour moi pratiquement nulle.

Fedora (et d'autres) dit faire uniquement du libre et c'est crédible car Fedora ne fait que du libre.

Franchement la charte Debian me fait rigoler.

> En revanche, je te laisse me trouver la licence libre du Satellite Server fourni par Red Hat.

C'est une excellente remarque. Les services Red Hat, et hébergés par Red Hat, ne sont pas libres.

La distribution et ce qui utilisent ses logiciels côté client (rhn, etc) sont libres.

Le reproche est tout à fait valable (du moins pour RHEL, car il n'y a pas de rhn, etc dans Fedora et toute l'infrastructure de Fedora (système de build, etc) est libre).

Mais il faut pondérer un peu. Ces logiciels proprios, sont comme les firmwares, ils ne tournent pas sur ton OS et mieux tu n'en as pas besoin pour utiliser ton OS et ta bécane ! C'est Red Hat qui en a besoin pour fournir un service que tu as acheté.
Notes comme rhn, etc ne posent aucun problème pour ceux qui veulent forker RHEL (centos, etc). RHEL reste fondamentalement libre. Les services vendu par Red Hat non.
D'ailleurs, on pourrait chipoter et dire que ces logiciels sont libres, mais que Red Hat ne les diffuse pas (c'est son droit, même si le logiciel est sous GPL).

En grattant bien chez Red Hat, tu dois pouvoir trouver du proprio (ou sous double licence) développé par Red Hat et diffuser par Red Hat. Je sais que ça existe, mais il faut bien chercher et je suis incapable de te les retrouver. Ca concerne principalement des petits produits très spécifiques pour l'embarqué.

S'il faut faire un reproche à Red Hat, ce n'est pas celui là. Red Hat (pour RHEL) supporte le proprio. Certes, Red Hat ne le diffuse pas, n'a pas de bugzilla pour les produits proprio, ne package pas de produit proprio, mais Red Hat bosse avec des boites proprio pour que RHEL soit adapté à des produits proprio. Par exemple pour avoir des benchmark qui arrachent sous Oracle ce qui aide à vendre du Oracle (et du RHEL).

Red Hat n'a pas de double discours consernant RHEL. D'ailleurs Red Hat a toujours des discours très honnètes.
Si tu fouilles Red Hat Magazine ( http://www.redhat.com/magazine/ ) tu trouveras un article en quatre parties sur les différences entre RHEL et Fedora. Pas uniquement technique, mais qui montre aussi la "colaboration" de Red Hat avec des boites proprios dans le cadre du projet RHEL (et uniquement celui ci, ça ne concerne pas Fedora).

Ce qui me gonfle particulièrement avec Debian, c'est que les discours (sa chartre) ne sont pas en accord avec la réalité.

> Cela ne remet pas en cause l'implication tant de Debian que de Red Hat pour le libre, hein.

Même si je n'apprécie pas certains aspects de Debian, je suis assez d'accord. Une chose est très claire, Debian ne nuit pas au libre, Debian aide le libre. Non-libre ne serait pas là ça ne profiterait pas à main. Les développeurs qui supportent du non-libre le feraient ailleurs.

> à moins que tu ne fasses fi de la ML debian-legal, de tout le travail effectué par debian pour bazarder du kernel les pilotes non libres, de toutes les GR allant dans le sens des libertés ?

Ca c'est très bien. Surtout par rapport à la chartre de Debian.

> Après, c'est bien les utilisateurs qui demandent du non libre non ?

Les utilisateurs, ce n'est pas Debian, ils n'ont une chartre.
Mais Debian qui prétend faire uniquement du libre, fait du non-libre ! Packagé par Debian, hébergé par Debian, diffusé par Debian, etc...

Fedora dit ne faire que du libre et ils ne font que du libre. L'utilisateur qui veut installer du proprio va voir ailleur que sur les sites officiels (supportés) par Fedora.
Fedora n'interdit pas livna (ce serait un comble), mais Fedora ne supporte pas livna (on y trouve des paquets proprio pour Fedora).
Debian n'interdit pas non-libre, mais Debian supporte pleinement non-libre.
Fedora fait que du libre et en supporte les conséquences (utilisateurs qui gueulent car il n'y a pas mp3, etc).
Que je sache, jamais les utilisateurs de Debian ne plaignent du manque de mp3, nvidia, libcss, acroreader, flash, etc... Ils n'ont pas de raison de se plaindre car c'est quasi pleinement supporté par Debian.

La charte de Debian est bien jolie sur le papier, mais dans la pratique elle ne vaut rien (à part casser les couilles aux développeurs pour bien spliter main de non-libre).

Si je suis une boite qui fait du proprio, Debian va faire le paquet, l'héberger, fournir la bande passante, faire une place dans son bugzilla, faciliter l'accès au paquet, etc...
Fedora rien.

Tu vois la différence ?

> Effectivement, tu ne trouvera jamais des paquets de non-free ou contrib sur les iso téléchargeables.
> Il n'y a aucune hypocrisie là-dedans.

Mon oeil.
Debian fait tout pour supporter non-libre, sauf que ce n'est pas dans les iso. La belle affaire. Durant l'installation on peut mettre du non-free ! Tout est indiqué, il n'y a rien à chercher. Et où sont les programmes non-free ? Sur le site de Debian. Où est le bugzilla associé ? Sur le site de Debian. Qui paye la bande passante ? Debian. Où est le système qui construit les paquets ? Toujours Debian.
Quand Fedora dit ne pas supporter le proprio, ben il le supporte pas. Les bug pour programmes proprios sont systématiquement fermés, il n'y a pas d'aide pour aller chercher les programmes proprios, Fedora n'héberge pas de proprio, etc...
J'oubliais ce détail, il n'y a pas de proprio sur les iso de Fedora.

Debian fait des contorsions pour se donner bonne conscience.

Dans une RHEL (qui se vend) il n'y a pas de proprio (sauf peut-être la version desktop (flash, etc)).

Certe ça ne concerne que les serveurs. Mais maintenant dans ce domaine, si les constructeurs veulent être placé sur Linux, ils *doivent* fournir des drivers libres.

> ou j'aurai un driver libre qui marche raisonnablement pour une carte graphique raisonnablement "moderne" (moins de 3 ans disons).

http://intellinuxgraphics.org/

Rpm n'est pas un système pour installer tout et n'importe quoi.
Ce n'est pas parce que le fichier ce termine par .rpm, qu'il s'installe sur un système utilisant rpm.
Sûr de chez sûr qu'il y a des paquets Ubuntu qui ne s'installent pas sur Debian et vice versa.

> j'ai pas la lib truc_bidule.so.6.12.0.

Et ?
Si le programme a besoin de libtruc_bidule.so.6.12.0, qu'il n'est pas sur la bécane ou sur un dépôt, que l'installation de libtruc_bidule.so.6.12.0 fait downgrader des librairies ou programmes, rpm a raison de ne pas installer le programme. C'est son job !

Ici tu montres seulement que rpm fait son boulot.

> Je n'ai JAMAIS eu ce genre de probleme avec dpkg

Ben utilises Fedora avec les dépôts Fedora Core, Fedora Extras et livna. Tu n'aura jamais ce genre de problème.

Tu ne parles pas d'un problème de rpm, mais de compatibilité de dépôt. Problème qui existe aussi bien pour les systèmes à base de dpkg que rpm.

> Debian a toujours ete plus que pointilleux concernant les questions de savoir si un composant de la distrib est libre ou pas.

C'est de l'humour ?
Depuis toujours Debian fait des paquets non-libre, fournit de la bande passante pour les diffuser, suit les bugs, etc...

Pour la sensibilisation, olpc est mentionné sur la page d'accueil de Red Hat.
Olpc sur Red Hat :
http://www.redhat.com/promo/onelaptop/
Olpc sur Fedora :
http://fedoraproject.org/wiki/OLPC

Red Hat a mis quelques développeurs sur le project et non des moindres (je pense à David Woodhouse, Cambridge et Christopher Blizzard notamment) :
http://www.redhat.com/promo/onelaptop/team.html

Olpc est une excellente idée. Il devrait y avoir plus de monde pour la concrétiser et en faire un succès.

> Ca existe depuis au moins un an donc si "quelques" vaut au moins 52 dans ton esprit, ok.

Tout le monde peut se tromper.

> Je n'ai jamais eu aucun probleme, notamment avec un xorg.conf modifié et jamais écrasé. Dpkg demande a l'utilisateur ce qu'il faut faire dans ces cas la, donc tu as le choix,

On ne parle pas de la même chose.

> Faux argument d'une part (comme dit auparavant), python peut être plus ou moins rapide que C.

Et les futurs OS seront écrit en Java. Ok, ok, ok...

> Tu peux m'expliquer en quoi avoir un systeme de plug-in rend un outil meilleur ?

S'il n'y a pas de plugin, en rien.

> Depuis, rpm court derriere dpkg.

Dpkg a les paquets "recommandés" et/ou "suggeré" et c'est tout de mieux que rpm.
Au-lieu d'affimer gratuitement que dpkg est mieux que rpm, dites ce que dpkg a de mieu.

> Apt utilisant un systeme de package plus performant n'a fait qu'exploiter ce potentiel.

Marche aussi avec rpm.
Dis ce que apt pour dpkg a de mieu que apt pour rpm.

> Mais visiblement, tu n'as pas vu les talks de Mark Shuttleworth, d'où ton incompréhension du mécontentement de beaucoup face à Ubuntu.

J'ai bien compris ton commentaire et ton "ressentiment". J'ai fait peu cas des "bruits".
Les promesses n'engagent que ceux qui les écoutent :-)

> J'ai comparé les deux, au fil des années j'ai bien eu le temps. Installer un rpm téléchargé parait toujours plus long qu'installer un .deb. Utiliser yum dans la command line prends une éternité alors qu'apt-get install prends 3 secondes. Lancer Synaptic ou le nouvel outil d'Ubuntu prends moins de temps que le frontend graphique de Yum, et le système de recherche est plus rapide aussi.

En gros, apt est plus rapide. C'est tout.

> Red Hat, SuSE et compagnie devraient ravaler leur fierté et se mettre au couple apt/dpkg.

Tu devrait regarder d'un peu plus près rpm au-lieu de seulement voir la vitesse d'installation d'un paquet.

Depuis combien de temps il y a la signature des paquets dans dpkg ? Quelques semaines alors que ça existe depuis dans années dans rpm. Comment se passe la vérification des fichiers installés lorsque ces fichiers ont été modifiés par prelink ? Mal avec dpkg, sans problème avec rpm. Peut-on les controlers par rapport à la signature ? Comment sont détecter les dépendances à la création du paquet ? etc...

Simplement car apt est rapide, tu penses que rpm est de la merde. Notes bien que apt et synaptic existent pour rpm et qu'ils sont aussi rapides.
Effectivement yum est lent par rapport à apt. Yum c'est du python et apt du C. Tu t'attendais à quoi ?
Yum a un système de plugin. Et apt ?
Les dépôts Yum sont des fichiers au format xml. Et apt ?
Peut-on faire des requêtes sur les dépôts apt comme on peut le faire avec repoquery : http://www.die.net/doc/linux/man/man1/repoquery.1.html (160 champs du format rpm sont interrogables ).

ETC, ETC...

Je connais mal dpkg/apt et j'ai fort probablement dit des conneries ici sur dpkg, mais rpm ce n'est pas de la merde. Et OUI, python est plus lent que le C.

> Tu réponds visiblement au premier degré à un post ironique

Tant mieux si je me suis trompé.

> Mais le problème avec Canonical, c'est que quand tu écoutes les talks de Mark Shuttleworth (et d'un certain nombre de ses fans), on a l'impression qu'Ubuntu est la meilleur chose qui soit jamais arrivée à Debian

Ben en un sens oui. Pour le projet Debian, il doit certainement être plus facile de récupérer Xorg 7.1 d'Ubuntu que Xorg 7.1 de Fedora.
Si Fedora améliore RPM, je pense que Debian en a rien à foutre. Si Ubuntu améliore dpkg, c'est que du bonheur pour Debian (et Fedora en a rien à foutre).

> Ubuntu a été créée pour booster Debian

Sûrement pas.

> pas pour la concurrencer.

Ubuntu concurrence (presque) tout le monde. Combien d'utilisateurs de Mandr(ake|iva) sont allez chez (K)Ubuntu ?
Un beau paquet. Et combien de développeurs ? Un beau paquet aussi.
Idem pour Fedora, Mepis, etc.
Canonical n'a pas un arbre à développeurs et utilisateurs. Les développeurs et les utilisateurs sont venus d'ailleurs.

> Et dans la pratique, bon nombre de développeurs Debian disent plutôt le contraire.

Je vais être dur, mais Debian avait un capitale de sympathie principalement à cause de apt et car ça faisait "élite" d'utiliser Debian. Pourtant le projet Debian (je ne parle pas de la distribution) merdait. Des ressources considérables mais pas de leader pour fixer un cap et le tenir (voir Sarge et ses 18 mois de retard, voir le retard considérable par rapport aux autres pour avoir AMD64 presque "out of the box" alors que Sarge sortait en même pour des "ça se fait plus" qui représentaient 0,01 % des bécanes, etc).
Quand Ubuntu est sorti, ça semblait une Debian (la distribution) sans les problèmes de Debian (le projet). Sauf pour les serveurs (mais pour 1 serveur il y a combien de desktop ?).

Quand Ubuntu est sorti, beaucoup on dit que c'était un gros coup de pied au cul de Debian. Ca se confirme.

Ceux qui participent à Debian ne sont pas contents. Et alors ?
Ont-ils réellement été spolié ?
Par vraiment, Ubuntu mène la dance et n'attend pas Debian, n'a pas (ou plus) besoin de Debian.

Ce sont surtout les utilisateurs d'Ubuntu qui ont gagné avec la création d'Ubuntu. Et surtout les ex-utilisateurs de Debian.

> le boulot fait par Ubuntu peut et doit être intégré à Debian si il est de qualité.

C'est le boulot de Debian :-)
Peut-être qu'au-delà de ces "broutilles", c'est surtout un manque de coopération (notamment dans les décisions qui orientent durablement les distributions) entre Debian et Ubuntu qui existe.
Mais; Et si Debian n'etait pas la référence des distributions basées sur Debian ? Et si aujourd'hui c'était Ubuntu ?
Et si finalement Ubuntu n'était plus basée sur Debian ?
Et si finalement c'était Debian qui aujourd'hui était basé sur Ubuntu ?
Et si Ubuntu est à Debian ce que Fedora est à RHEL, alors Debian est basé sur Ubuntu.
C'est sur Fedora et Ubuntu que vont les développeurs. Pas sur Debian et RHEL.

Avant la création d'Ubuntu, l'attractivité de Debian était presque une anomalie.

> D'un autre cote

T'as oublié d'enlever cet apostrophe.

> la mouvance actuelle des gros projets qui cherchent à améliorer leur fréquence (suite aux demandes renouvellées des utilisateurs).

Il y a aussi la demande des développeurs !
Si le projet ne bouge pas, les développeurs vont voir ailleurs.

> Il serait bon qu'Ubuntu annonce officiellement l'intention de ne rien reverser à Debian.

Il est un peu crétin ton propos. Ubuntu fait du taff, si ça plait à Debian, Debian le reprend. C'est du logiciel libre, Debian n'a pas à attendre l'autorisation d'Ubuntu. Il est plus facile de reprendre quelque chose de développé que de le développer.
Debian doit aussi avoir plein de taff de chez Red Hat ou Novell, Debian n'a pas attendu que Red Hat ou Novell le "reverse" à Debian.

Puis, Ubuntu ne doit pas "reverse" son taff à Debian, mais il doit le mettre en upstream. Comme ça tout le monde en profite. Un bon exemple est AIGLX. C'était développé dans le cadre de Fedora, maintenant c'est dans Xorg (depuis la version 7.1).

> Comme ça on pourrait s'extasier quand par un malheureux concours de circonstance un micro patch bricolé avec les pieds par un incompétent de Canonical se retrouvait intégré par erreur à Debian.

C'est Debian qui maintient Debian ou c'est Ubuntu ?

Il semble un peu au point mort. Néanmoins les fonctionnalités d'un nouveau init ont été largement débatues sur mailing et validées. Il y a un solide consensus. Il manque un développeur de disponible pour le développer.

> le nouveau media-manager de kde 3.5.4 fait la gestion HAL des périphériques USB

C'est ce que fait aussi Gnome-volume-manager.
Mais ce n'est pas tout à fait la même chose que kudev transposé vers HAL. Ils (media-manager et gnome-volume-manager) ne configurent pas les fichiers *.hdi de HAL. Par exemple la configuration de HAL par défaut (du moins celle livrée dans Fedora) monte les périphériques amovibles de moins de 2 Go sans cache.
Il serait tout à fait pertinant d'avoir un outil qui édite les fichiers *.hdi (plus probablement qui en crée de nouveaux qui dans certains cas spécifiques écrasent la valeur par défaut).
Il y a un gnome-volume-manager-properties mais il n'édite pas les fichiers *.hdi, il configure "seulement" le fonctionnement de gnome-volume-manager.

Puisque c'est demandé gentillement, OK. Mais un peu plus tard.

Parce que ce n'est pas un avion.