mpv/DOCS/xml/fr/users-vs-dev.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- synced with 1.14 -->
<appendix id="users-vs-dev">
<title>Lamentations du d<>veloppeur</title>

<sect1 id="gcc-296">
<title>GCC 2.96</title>

<formalpara>
<title>La toile de fond:</title>
<para>
La s<>rie GCC <emphasis role="bold">2.95</emphasis> est une version GNU officielle et
la version 2.95.3 de GCC est la version la plus exempte de bogues de toute la s<>rie.
Nous n'avons jamais remarqu<71> de probl<62>mes de compilation que nous pourrions attribuer
<EFBFBD> GCC 2.95.3. A partir de Red Hat Linux 7.0, <emphasis role="bold">Red Hat</emphasis>
a inclus une version CVS lourdement patch<63>e de GCC dans sa distribution et l'a nomm<6D>
<emphasis role="bold">2.96</emphasis>. Red Hat a inclus cette version parce que GCC
3.0 n'<27>tait pas termin<69> <20> ce moment l<>, et ils avaient besoin d'un compilateur
fonctionnant sur toutes leurs plateformes support<72>es, incluant IA64 et s390. Le
distributeur Linux <emphasis role="bold">Mandrake</emphasis> a <20>galement suivi
l'exemple de Red Hat et a lanc<6E> la diffusion de GCC 2.96 avec sa s<>rie Linux-Mandrake 8.0.
</para>
</formalpara>

<formalpara>
<title>Les <20>v<EFBFBD>nements:</title>
<para>
L'<27>quipe GCC a ni<6E> tout lien avec GCC 2.96 et a publi<6C> une
<ulink url="http://gcc.gnu.org/gcc-2.96.html">r<EFBFBD>ponse officielle</ulink>
<EFBFBD> GCC 2.96. De nombreux d<>veloppeurs <20> travers le monde ont commenc<6E> <20> avoir des
probl<EFBFBD>mes avec GCC 2.96, et ont donc recommand<6E> d'autres compilateurs. Par Exemple
<ulink url="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</ulink> et
<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>.
D'autres liens int<6E>ressants sont
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
Linux kernel news flash about kernel 2.4.17</ulink>
et le <ulink url="http://www.voy.com/3516/572.html">Forum Voy</ulink>.
<application>MPlayer</application> a <20>galement souffert des probl<62>mes intermittents qui
ont tous <20>t<EFBFBD> r<>solus en passant <20> une version diff<66>rente de GCC. Plusieurs projets en
commenc<EFBFBD> <20> impl<70>menter des contournements pour quelques-uns des probl<62>mes de 2.96, mais
nous avons refus<75> de r<>parer les bogues des autres, surtout parce que certains
contournements peuvent impliquer une p<>nalit<69> sur les performances.
</para>
</formalpara>

<para>
GCC 2.96 n'autorise pas les caract<63>res <literal>|</literal> (pipe) dans les
commentaires assembleur parce qu'il supporte aussi bien la syntaxe Intel que la
syntaxe AT&amp;T et que le caract<63>re <literal>|</literal> est un symbole dans la
variante Intel. Le probl<62>me est qu'il ignore <emphasis role="bold">silencieusement</emphasis>
le bloc assembleur entier. Cela est th<74>oriquement fix<69> maintenant, GCC affichant
un warning au lieu de sauter le bloc.
</para>

<formalpara>
<title>Le pr<70>sent:</title>
<para>
Red Hat dit que GCC 2.96-85 et sup<75>rieur est r<>par<61>. La situation s'est en effet
am<EFBFBD>lior<EFBFBD>e, mais nous voyons toujours des probl<62>mes sur les listes de diffusion qui
disparaissent avec un compilateur diff<66>rent. Dans tous les cas cela ne peut plus durer.
Normalement un GCC 3.x mature r<>soudra les probl<62>mes. Si vous voulez compiler avec 2.96
passez l'option <option>--disable-gcc-checking</option> <20> <filename>configure</filename>.
Rappelez-vous que vous <20>tes seul et donc <emphasis role="bold">de ne pas rapporter de bogues</emphasis>.
Si vous le faites, vous serez juste insult<6C> voir banni de nos listes de diffusion car
nous en avons plus qu'assez des empoignes sur GCC 2.96. S'il vous pla<6C>t, restons-en l<>.
</para>
</formalpara>

<para>
Si vous avez des probl<62>mes avec GCC 2.96, vous pouvez obtenir les paquetages 2.96-85
sur le <ulink url="ftp://updates.redhat.com">serveur ftp</ulink> de Red Hat, ou
d'utiliser les paquetages 3.0.4 offerts avec la version 7.2 et sup<75>rieur. Vous pouvez
<EFBFBD>galement obtenir les <ulink url="ftp://people.redhat.com/jakub/gcc/3.2-11/">paquets gcc-3.2-11</ulink>
(non officiels, mais fonctionnant bien) et vous pouvez les installer avec le GCC 2.96
que vous avez d<>j<EFBFBD>. Mplayer les d<>tectera et utilisera 3.2 au lieu de 2.96. Si vous ne
voulez pas ou ne pouvez pas utiliser les paquetages binaires, voici comment vous pouvez
compiler GCC 3 depuis les sources:
</para>

<procedure>
<step><para>
  Allez sur la
  <ulink url="http://gcc.gnu.org/mirrors.html">page des miroirs GCC</ulink>
  et t<>l<EFBFBD>chargez <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename> o<>
  <replaceable>XXX</replaceable> est le num<75>ro de version. Ceci inclue le compilateur C
  complet et est suffisant pour <application>MPlayer</application>. Si vous voulez
  aussi C++, Java ou certaines autres fonctions avanc<6E>es de GCC,
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> pourrait mieux convenir <20> vos besoins.
  </para></step>
<step><para>
  D<>compressez l'archive avec
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  </para></step>
<step><para>
  GCC n'est pas construit depuis le r<>pertoire source lui-m<>me comme c'est le cas pour
  la plupart des programmes, mais a besoin d'un r<>pertoire de construction <20> l'ext<78>rieur
  du r<>pertoire source. Vous devez donc cr<63>er ce r<>pertoire via
  <screen>mkdir gcc-build</screen>
  </para></step>
<step><para>
  Ensuite vous pouvez proc<6F>der <20> la configuration de GCC dans le r<>pertoire de
  construction, mais vous aurez besoin de le configurer depuis le r<>pertoire source:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Compilez GCC en tapant cette commande dans le r<>pertoire de construction:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Maintenant vous pouvez installer GCC (en root) en tapant
  <screen>make install</screen>
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Distribution binaire</title>

<para>
<application>MPlayer</application> contenait pr<70>c<EFBFBD>demment du code source du projet
OpenDivX, qui interdit toute redistribution binaire. Ce code <20> <20>t<EFBFBD> retir<69> depuis la
version 0.90-pre1 et le fichier restant <filename>divx_vbr.c</filename> qui est
d<EFBFBD>riv<EFBFBD> des sources OpenDivX <20> <20>t<EFBFBD> plac<61> sous GPL par ses auteurs au moment de la
version 0.90pre9. Vous <20>tes maintenant invit<69> <20> cr<63>er des paquetages binaires si vous
en avez l'utilit<69>.
</para>

<para>
D'autres imp<6D>ratifs pour la redistribution <20>taient les optimisations de compilation
pour l'architecture binaire. <application>MPlayer</application> supporte maintenant
la d<>tection CPU (passez l'option <option>--enable-runtime-cpudetection</option>
<EFBFBD> <command>configure</command>). Elle est d<>sactiv<69>e par d<>faut parce quelle implique un petit
sacrifice de vitesse, mais il est maintenant possible de cr<63>er des binaires qui
fonctionneront sur les diff<66>rents membres de la famille des CPUs compatibles Intel.
</para>
</sect1>


<sect1 id="nvidia-opinions">
<title>nVidia</title>

<para>
Nous n'aimons pas le fait que <ulink url="http://www.nvidia.com">nVidia</ulink> ne
fournisse que des pilotes binaires (<28> utiliser avec XFree86), qui sont souvent bogu<67>s.
Nous avons eu de nombreux rapports sur
<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
<EFBFBD> propos de probl<62>mes relatifs <20> ces pilotes closed-source et <20> leur pi<70>tre qualit<69>,
leur instabilit<69> et le pi<70>tre support utilisateur et expert.
Beaucoup de ces probl<62>mes continuent de se r<>p<EFBFBD>ter. Nous avons contact<63> nVidia
r<EFBFBD>cemment, et ils nous ont dit que ces bogues n'existaient pas, que l'instabilit<69>
<EFBFBD>tait caus<75>e par de mauvais chips AGP, et qu'ils n'avaient pas re<72>u de rapports de
bogues (comme la ligne violette). Donc si vous avez un probl<62>me avec votre carte
nVidia, nous vous conseillons de mettre <20> jour le pilote nVidia et/ou d'acheter une
nouvelle carte m<>re ou de demander <20> nVidia de fournir des pilotes open-source. Dans
tous les cas, si vous utilisez les pilotes binaires nVidia et rencontrez des probl<62>mes
li<EFBFBD>s, soyez conscient que vous ne recevrez que peu d'aide de notre part car nous avons
trop peu de pouvoir pour am<61>liorer les choses.
</para>
</sect1>


<sect1 id="joe-barr">
<title>Joe Barr</title>

<para>
Joe Barr est devenu tristement c<>l<EFBFBD>bre en d<>cembre 2001 pour avoir <20>crit une
moins-que-favorable critique de <application>MPlayer</application> appel<65>e
<ulink url="http://www.linuxworld.com/story/32880.htm">MPlayer: The project from hell</ulink>.
Il a trouv<75> <application>MPlayer</application> difficile <20> installer, et en a conclu
que les d<>veloppeurs n'<27>taient pas amicaux et que la documentation <20>tait incompl<70>te et
insultante. Vous <20>tes seul juge. Il <20> ensuite mentionn<6E> n<>gativement Arpi dans ses
<ulink url="http://www.linuxworld.com/story/32887.htm">10 pr<70>dictions Linux pour 2002</ulink>.
Puis dans une critique de xine appel<65>e
<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink>
il a continu<6E> d'alimenter la controverse. Ironiquement <20> la fin de cet article il cite
son <20>change avec G<>nter Bartsch, l'auteur original de <application>xine</application>,
qui r<>sume parfaitement la situation:

<blockquote><para>
Toutefois, il a ajout<75> qu'il avait <20>t<EFBFBD> &quot;surpris&quot; par mon papier <20> propos de <application>MPlayer</application>
et pensait que c'<27>tait d<>loyal, me rappelant que c'est un projet de logiciel libre.
&quot;Si vous ne l'aimez pas,&quot; <20> dit Bartsch, &quot;vous <20>tes libre de ne pas l'utiliser.&quot;
</para></blockquote>

Presque deux ans apr<70>s, en octobre 2003, il a <20>crit un autre article appel<65>
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink>.
Dans celui-ci il arrive aux conclusions suivantes:

<blockquote><para>
Je dois dire qu'il y a eu des am<61>liorations dans le nombre de fonctions, au
niveau des performances, et dans la documentation. Ce n'est toujours pas
l'installation la plus facile au monde, sp<73>cialement pour les d<>butants,
mais c'est un petit peut mieux qu'avant.
</para></blockquote>

et

<blockquote><para>
Mais plus important, je n'ai pas remarqu<71> de r<>cents commentaires <20> propos
des abus des utilisateurs. Je suppose que je m<>rite de la reconnaissance pour
cela, m<>me si j'en fait partie moi-m<>me. Arpi et le reste de l'<27>quipe du projet
doivent ressentir cela aussi, car ils ont pris soin de me le rappeler dans une
section sp<73>ciale de la documentation incluse dans l'archive. Comme je l'ai dit
au d<>but, certaines choses n'ont pas chang<6E>es du tout.
</para></blockquote>

Nous n'aurions pas pu r<>sumer mieux nos sentiments <20> l'<27>gard de Joe Barr:
&quot;Ce n'est toujours pas l'article le plus honn<6E>te ou le plus recherch<63> au monde,
mais c'est meilleur qu'avant.&quot; Esp<73>rons que la prochaine fois nous r<>pondrons
mutuellement <20> nos attentes. De toute fa<66>on, le chemin de la maturit<69> passe
uniquement par l'<27>ge, et peut-<2D>tre en faisant fi des empoignades.
</para>

</sect1>
</appendix>