Bienvenue à cette soixantième édition de Brave Gnu World. Cela signifie que BGW existe aujourd'hui depuis 5 ans. Une demi-décade. Inquiétant. Nous en rediscuterons plus bas.

K3b

Après que le PC d'un ami eut été tout fraichement installé avec GNU/Linux, la question "comment puis-je graver un CD ?" a longtemps été une des choses qui, venant d'un utilisateur normal, pouvaient donner des sueurs froides à l'administrateur bénévole.

Bien que des programmes tels que cdrecord [5] s'avèrent fiables et adaptés, autant pour les utilisateurs professionnels que privés, l'usage de la ligne de commande pose régulièrement des difficultés à l'administrateur, le créateur et l'utilisateur, ce qui a certainement incité Jörg Schilling, l'auteur des cdrtools, à abandonner le suivi des utilisateurs.

En outre, les propriétaires d'un graveur de DVD furent peu aidés par la suppression de la possibilité de graver des DVD à l'aide de la version livrée en tant que Logiciel Libre sous licence GPL. La version complète n'est disponible qu'en version non-libre, c'est-à-dire propriétaire.

Fort heureusement, il existe à cette fin les dvd+rw tools [6], mais dont l'utilisation repose également sur la ligne de commande. Dans le cas de cdrecord, des interfaces graphiques apparurent très tôt, malheureusement elles étaient souvent fragiles (sujettes à plantages) et n'étaient que très rarement attractives.

De plus, leur champ d'action se réduisait souvent à une tâche particulière, qui se définissait plus par une technique précise que par une fonctionnalité pour l'utilisateur. Ainsi la lecture de CDs était rarement prévue, bien que cela paraisse évident pour beaucoup d'utilisateurs, et que ces deux fonctionnalités soient intimement liées dans le cadre du processus de copie.

C'est dans cette situation que Sebastian Trueg s'est retrouvé à nouveau, quand en 1998 il a voulu fermer définitivement le chapitre Windows chez lui. Aucune des possibilités proposées ne lui procurait une véritable satisfaction, c'est pourquoi il a commencé à travailler sur les fonctionnalités audio de K3b [7]. Et c'est plus particulièrement grâce au succès qui a récompensé son travail, qu'il est depuis resté motivé pour poursuivre son investissement personnel dans le projet.

Ainsi l'enthousiasme et le retour positif des utilisateurs ont constitué des facteurs non négligeables, qui ont porté le projet pendant des années. L'autre facteur est bien-sûr constitué par les développeurs. En plus des développeurs comme Chris Kvasny, qui a développé les fonctions de lecture et d'écriture de Vidéo-CD (VCD) et qui depuis fait partie tout comme Sebastian des développeurs permanents, on compte aussi des développeurs occasionnels comme Thomas Froescher -- à qui on doit la fonction de lecture DVD Vidéo -- et Klaus-Dieter Krannich, qui a contribué à l'amélioration du support matériel.

Le projet a ensuite connu une impulsion significative en 2003, quand SuSE a permis à Sebastian Trueg de travailler à plein temps sur K3b, dans le cadre d'un stage de trois mois -- c'est à cette période qu'est né le support pour l'écriture de DVDs avec l'aide de growisofs, issu lui-même des outils "dvd+rw-tools" évoqués plus haut.

Et enfin : que serait un projet si vaste sans une bonne finition graphique ? La facture extraordinaire et originale de l'interface graphique de K3b est due à Ayo, [8] dont le site mérite une visite, en raison de ses oeuvres extêmement belles, ses écrans-Splash et ses cartes de voeux GNU/Linux. Qui plus est, depuis la version 0.11 de K3b, le nouveau thème graphique "everaldo", du même auteur que les icônes "Crystal" de KDE, est utilisé.

Si après lecture de ces lignes vous avez l'impression que K3b n'est "juste" qu'une très bonne interface graphique pour des outils comme cdrecord, growisofs, cdrdao et mkisofs, alors je dois m'excuser auprès de Sebastian et des autres auteurs de K3b, car effectivement K3b va bien au-delà. En fait, il utilise cdrecord uniquement pour le processus d'écriture. Tout le reste - par exemple la reconnaissance du matériel ou l'affichage des informations sur le contenu du CD - est fait directement par K3b.

Tout ceci permet à l'utilisateur de K3b l'utilisation optimale des fonctionnalités proposées, comme par exemple la détermination de la vitesse d'écriture d'un média monté ou la détermination préalable de la taille des supports vierges pour une utilisation optimale de la capacité du disque.

Contrairement à de nombreuses autres applications, qui ne sont que des interfaces graphiques, il n'y a par exemple aucun problème pour utiliser K3b en réseau, le processus de gravure pouvant être exécuté sur un serveur (éventuellement déjà occupé par diverses requètes et compilations) tandis que l'affichage est déporté sur un autre poste de travail.

Et pour clore cette introduction ajoutons que si l'on insère un CD-Audio K3b le reconnaît, recherche, selon votre configuration, en local ou sur la base de données FreeDB [9] via internet, le nom de l'artiste, le titre et le sommaire, et affiche le résultat aussitôt. Et grâce aux menus contextuels accessibles par un clic droit de la souris, il est possible de lire le contenu complet du CD ou seulement certaines pistes, et les données peuvent ensuite aussi être converties directement, au choix, en Flac, MP3, OGG-Vorbis ou autre format audio.

Pour la gravure de CD-audio l'autre méthode fonctionne également : les données au format souhaité peuvent être insérées dans le projet, et K3b en fait ensuite un CD-audio -- qui peut même contenir, si vous le lui demandez, des pistes bonus cachées. Et, pour celui qui en voudrait plus encore, K3b utilise une architecture modulaire, qui autorise l'ajout de fonctionnalités supplémentaires.

K3b a été écrit en C++ pour l'environnement KDE, et il est intégré au dépot kdeextragear-1 CVS, ce qui lui permet de profiter des possibilités de traduction et de déboguage du projet KDE. Mais, il fonctionne également sans problème sous GNOME et d'autres environnements, la présence de KDE n'est donc pas une obligation. Et comme K3b, tout comme KDE lui-même, est publié comme logiciel libre sous la Licence Publique Générale GNU (GPL), l'adaptation pour d'autres environnements est bien évidemment possible et autorisée.

Pour Sebastian, il est clair en tout cas que la priorité est la sortie de la version 1.0, toujours prévue pour cette année, la version en cours contenant déjà les fonctionnalités souhaitées. Parallèlement la priorité est également donnée à la recherche de bogues et à la résolution de certaines difficultés.

Ainsi, Sebastian s'attend a avoir, entre autres complications, des difficultés avec les lecteurs CD qui ne satisfont pas au standard de commande "Multi Media Command" (MMC). À ce sujet, il semblerait, selon des informations de Jörg Schilling, que tous les appareils commercialisés après 1999 soient conformes à ce standard. Il se pourrait donc qu'il soit déjà difficile de trouver encore de tels lecteurs, qui pourraient servir pour le test en question.

La prochaine étape vers de nouvelles fonctionnalités doit être la possibilité de copier des DVD-Vidéo, l'obstacle principal étant de faire un DVD-5 à partir d'un DVD-9 par re-quantification, car sinon la capacité des disques vierges actuels ne suffit pas.

Il existe également une volonté - liée à l'étape précédente mais n'en dépendant pas obligatoirement - de créer un module général de Video-Transcoding pour tout projet CD-vidéo et DVD-vidéo dans K3b. Il serait ainsi possible de créer des CD-vidéo et DVD à partir de n'importe quel format vidéo.

Les volontaires sont les bienvenus, en priorité dans le domaine de la vidéo, et plus particulièrement pour le transfert de la lecture des DVD vidéos de transcode vers libdvdread et pour le travail sur la couche Transcoding pré-citée sur la base de transcode/mencoder. De l'aide serait également appréciée pour le travail de simplification des menus, puisque K3b tient à pouvoir être utilisé par les débutants, sans qu'il soit besoin de consulter la documentation.

Et pour ceux qui trouveraient que le développement général n'est pas assez rapide, mais qui n'auraient ni le temps ni les connaissances suffisantes pour s'y investir, rappelons que l'équipe de développement accepte aussi volontiers tout soutien financier -- un lien existe sur la page d'accueil du site de K3b. [7]

Vous aurez remarqué que nous avons accordé beaucoup de place ici à ce projet, et il a été examiné dans le détail pour des raisons bien précises. En effet, Sebastian et les autres auteurs ont fait un travail remarquable : depuis le démarrage "propre" en tant que logiciel libre sous une licence bien connue, jusqu'à la coopération communautaire, en passant par la véritable orientation "utilisateur final", le souci de simplification de l'interface, et la possibilité pour les non-techniciens de pouvoir également participer au projet indirectement par un soutien financier.

À partir de là, et tant que la lecture et l'écriture de CDs et DVDs compteront pour beaucoup de personnes parmi les besoins les plus immédiats, la situation et les perspectives de développement devraient être suivies de très près.

Matériel et pilotes

On a déjà parlé du problème des portables et des Logiciels Libres -- en particulier GNU/Linux -- dans le numéro 48 [10]. Toutefois, la question de savoir dans quelle mesure il est acceptable qu'un fabricant de matériel impose à son client le choix du logiciel et donc du domaine d'application du matériel est restée sans réponse.

D'où la question des pilotes propriétaires pour les systèmes d'exploitation libres, un phénomène qui est devenu apparent récemment.

Du matériel sans pilote adapté est inutile.

Cette déclaration rencontre probablement vite une simple et large approbation. Lorsque le matériel ne peut pas être piloté, il devient un gaspillage et il est, au mieux, un poids mort. Dans ce cas un portable qui n'a pas de pilote de gestion de consommation -- et par là même de durée de fonctionnement -- devient, de même, un parasite.

Du matériel avec un pilote propriétaire est en partie inutile.

Naturellement, le matériel peut aussi être fondamentalement contrôlé par un pilote propriétaire. Et, sans même penser à la sécurité -- ils font tout de même tourner du code inconnu, et souvent avec privilèges -- on pourrait d'abord espérer un support complet. Or suivent, au contraire, deux raisons pour lequelles ce n'est pas le cas.

En premier, voici le cas classique où le matériel ne pourra être utile que pour les applications prévues ou même tolérées par le fabricant. Qu'un problème imprévu survienne ou qu'on envisage un autre type d'application, alors il n'y a pas de solution directe. Un exemple serait, ici, l'idée d'utiliser la puissance des contrôleurs graphiques comme un "second processeur".

Un second exemple place l'utilisateur dans un cas classique de dépendance. Le matériel perd rapidement son utilité si le fabricant se retire du marché, s'il ne supporte pas le bon système d'exploitation, la bonne version ou le bon type ou s'il perd l'intérêt pour la maintenance d'un produit, préférant pousser vers un nouveau matériel.

Aussi le temps durant lequel le matériel peut être utilisé est dans une grande mesure une décision du fabricant, pas de l'utilisateur.

Du matériel avec des pilotes libres est d'une utilité maximale.

Si les pilotes existent en version libre, cette dépendance est caduque. Les utilisateurs ont alors non seulement la liberté d'adapter (ou de faire adapter) le pilote de façon à ce qu'il réponde de manière optimale à ses besoins, mais ils peuvent également en cas de besoin le porter sur d'autres versions du système d'exploitation voire même sur d'autres systèmes d'exploitations.

Le matériel peut alors être monté dans n'importe quelles conditions. Dans la plupart des cas il peut même dévoiler des performances que souvent le fabricant lui-même n'imaginait pas possibles. Les personnes aujourd'hui assez âgées pour avoir possédé un un Atari ST connaissent bien ce phénomène.

Avant tout l'utilisateur est indépendant du fabricant et peut décider librement de quelle manière et pour combien de temps le matériel lui sera utile.

Le matériel avec les spécifications complètes est presque aussi utile.

Même si un fabricant ne peut ou ne veut pas écrire lui-même un pilote libre, il a toujours la possibilité de communiquer le descriptif complet du périphérique. Cela nécessite ensuite certes un peu plus de travail qu'avec des pilotes déjà disponibles sous forme libre, mais cela constitue déjà une avancée vers l'utilité et la liberté d'indépendance évoquées plus haut.

Résultat intermédiaire

Ainsi, si on examine la valeur du matériel sur la base de son utilité, alors il devient clair que du matériel qui possède un pilote en logiciel libre a une grande valeur. Du matériel avec un pilote propriétaire est quelque part entre moyennement utile et totalement inutile.

En conséquence, on devrait réclamer tout ou partie du prix ou même retourner le matériel au cas où il ne dispose que de pilotes propriétaires. Dans le cas des portables, où il n'existe pas de pilotes pour la totalité des composants intégrés, d'où un poids supplémentaire et une consommation accrue, on devrait réclamer des compensations.

Pilotes propriétaires pour du logiciel libre

Dans le passé, il était d'usage que les pilotes propriétaires soient disponibles seulement pour des systèmes d'exploitation propriétaires et, du fait de la dépendance déjà ressentie, la dépendance au logiciel passait inaperçue.

Plus récemment, des pilotes propriétaires pour des systèmes d'exploitation libres sont devenus disponibles, particulièrement pour GNU/Linux. Par exemple, les cartes réseau sans fil intégrées pour portable Intel Centrino, les modems internes ou même les cartes graphiques NVidia.

Maintenant, il peut sembler logique de saluer comme un progrès le passage de "totalement inutile" à "partiellement utile". Cette opinion semble bien s'étendre -- les pilotes propriétaires sont acclamés sur les forums GNU/Linux sans aucun esprit critique.

On connaît déjà la perte progressive de liberté qui provient d'une tactique de saucissonage -- "Quelle différence fait un petit pilote, après tout?". Elle a déjà été évoquée dans cette colonne par le passé à maintes reprises et nous ne developperons pas à nouveau ces arguments.

Cependant, la plupart des utilisateurs ne comprennent pas qu'en acceptant et en utilisant les pilotes propriétaires, ils créent un climat dans lequel ils éliminent l'avantage concurrentiel des fabriquants qui nous offrent le matériel avec des logiciels libres.

En plus, cette attitude affaiblit considérablement l'incitation à développer des logiciels libres -- suffisamment pour empêcher le développement d'un pilote en logiciel libre.

Il y a quelques années, il y a eu un boycott réussi des cartes graphiques Matrox permettant l'obtention de spécifications pour pouvoir écrire un pilote convenable en logiciel libre. Beaucoup de gens utilisent aujourd'hui sans réfléchir les pilotes propriétaires de NVidia et accueillent ceux-ci comme un progrès.

Un autre cas est celui du "Driverloader" propriétaire qui intervient sur les cartes Intel Centrio Wavelan, et dont l'existence a assurément handicapé sérieusement le projet de logiciel libre "ndiswrapper" [11], même s'il est difficile de trouver des chiffres précis sur ce sujet.

Évidemment l'argumentation avancée par les concepteurs du Driverloader paraît compréhensible : ils ne gagnent rien sur le matériel et sont donc dans l'obligation de tirer leurs profits d'ailleurs. Or ceci néglige deux facteurs.

Premièrement c'est un problème créé par les fabricants eux-mêmes, et qui devrait être résolu au coeur même de l'entreprise -- et tout irait mieux si le fabricant était confronté à une résistance similaire. Deuxièmement, chaque versement effectué à l'entreprise en question revient à financer l'entrave au développement d'un pilote libre.

Personnellement je serais prêt à payer le double du prix initial pour obtenir un pilote libre. Car en y réfléchissant, on peut concevoir aisément de faire un don de 30 Euro à l'équipe du ndiswrapper, plutôt que de payer 15 Euro pour le pilote propriétaire.

Notre environnement

Il appartient effectivement à chacun d'entre nous de créer les conditions pour que soient privilégiés les fabricants qui livrent leur matériel avec des pilotes libres, ou tout au moins rendent publiques leurs spécifications complètes.

Celui qui continue à intégrer des pilotes propriétaires dans les systèmes d'exploitation libres devrait bien avoir conscience qu'il sera en partie responsable si à l'avenir les tout nouveaux matériels achetés ne sont pas supportés.

Et pour conclure...

Il est vrai que cette discussion ne date pas d'hier et dans les discussions sérieuses personne, par expérience, n'en contredira les arguments et en particulier le jugement porté sur l'utilité.

Au contraire, l'argumentaire selon lequel l'entreprise risque de perdre son "Mojo", son "je ne sais quoi", ses secrets de fabrication si elle publie ses pilotes sous forme de logiciels libres ou si elle rend publiques les spécifications du matériel revient souvent.

Non seulement la preuve de cette affirmation est toujours à faire, mais il y a même des indices tangibles selon lesquels il s'agit en fait d'un mythe. C'est pour ces mêmes raisons par exemple qu'a été entretenu le secret autour la technologie "Intel SpeedStep" des processeurs Centrino.

Afin d'introduire le support de cette technologie sous GNU/Linux, Bruno Ducrot s'est vu dans l'obligation de mener une réflexion très intensive sur la façon dont celle-ci pouvait être implémentée, afin d'écrire le pilote grâce auquel cette technologie pourrait être utilisée.

Au final, Bruno Ducrot -- et ainsi l'ensemble de la communauté du logiciel libre -- en a appris beaucoup plus sur cette technologie que s'il s'était contenté de lire les spécifications. Et s'il avait eu accès aux spécifications, il n'aurait eu aucune raison d'étudier le sujet de manière si exhaustive.

Le maintien du secret autour de cette technologie n'a donc pas eu l'effet escompté. La technologie Intel SpeedStep n'en a pas été moins dévoilée, bien au contraire.

Malheureusement, chez de nombreux constructeurs, cette évidence n'est pas encore remontée jusqu'à la Direction; c'est pourquoi c'est souvent la Direction elle-même qui fait obstacle de manière incompréhensible. Car du point de vue des fabricants un pilote logiciel libre est justement l'élément qui apporte plus de valeur à leur propre produit et fait ainsi réfléchir la concurrence.

Brave GNU World a 5 ans !

Ainsi Brave GNU World est maintenant officiellement actif depuis 5 ans. En cette demi-décennie il y a eu 60 numéros, soit au total 1232 Ko de texte HTML, qui ont été publiés sur le net dans 10 langues différentes.

Ceci a été possible grâce à l'aide de nombreux bénévoles dans le monde entier -- de l'Asie à l'Europe en passant par l'Amérique du Sud. Je n'aurai donc qu'un mot pour eux : Merci !

De même, mes remerciements vont à ceux qui se sont investis, par leurs commentaires, questions, idées ou propositions de projets. Les meilleurs numéros sont la plupart du temps issus de VOS propositions.

Et bien sûr je remercie aussi les lecteurs de Brave GNU World pour leur fidélité. Et pour tous ceux qui jusqu'ici n'ont été que de "simples" lecteurs, je voudrai les inviter à s'investir eux-mêmes, tranquillement. Que ce soit par des idées, des commentaires, des questions, des suggestions, ou toute autre chose -- et naturellement par des projets. Envoyer le tout comme d'habitude à l'adresse email désormais bien connue [1], on ne change rien de ce côté-là. :)