view DOCS/xml/ru/users-vs-dev.xml @ 19974:b71fdb42f9dc

nit: Subversion revision numbers are referenced as r12345.

<?xml version="1.0" encoding="koi8-r"?>
<!-- synced with r19685 -->
<appendix id="users-vs-dev">
<title>Плач разработчиков</title>

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

<formalpara>
<title>Предпосылки:</title>
<para>
GCC <emphasis role="bold">2.95</emphasis> серий &mdash; это официальный GNU релиз и версия 2.95.3
&mdash; максимально свободная от ошибок в этой серии. Мы никогда не замечали
проблем компиляции, которые можно было бы отнести на счёт gcc-2.95.3.
Начиная с RedHat Linux 7.0, <emphasis role="bold">Red Hat</emphasis> включили сильно
пропатченную CVS версию GCC и назвали её <emphasis role="bold">2.96</emphasis>.
RedHat включили эту версию в дистрибутив, поскольку в то время GCC 3.0 не был
завершён, а им требовался компилятор, который бы хорошо работал на всех
поддерживаемых платформах, включая IA64 и s390. Дистрибьютор Linux
<emphasis role="bold">Mandrake</emphasis>, последовал примеру Red Hat и начал поставки
GCC 2.96 с Linux-Mandrake серии 8.0.
</para>
</formalpara>

<formalpara>
<title>Заявления:</title>
<para>
Команда GCC отрицает все связи с GCC 2.96 и даже выпустила 
<ulink url="http://gcc.gnu.org/gcc-2.96.html">официальный ответ</ulink>
на GCC 2.96. У многих разработчиков по всему миру возникали проблемы с
GCC 2.96, и некоторые проекты, среди них 
<ulink url="http://avifile.sourceforge.net/news-old1.htm">avifile</ulink>,
начали рекомендовать другие компиляторы.
Прочие интересные ссылки &mdash; это 
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
Linux kernel news flash о ядре 2.4.17</ulink>
и
<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>.
<application>MPlayer</application> также претерпевал различные проблемы,
которые разрешались переходом на другую версию GCC. Часть проектов начала
реализовывать обходы для некоторых проблем 2.96, но мы отказались исправлять
ошибки других людей, в том числе поскольку некоторые такие обходы привели бы
к потере производительности.
</para>
</formalpara>

<para>
GCC 2.96 не допускает символ <literal>|</literal> (pipe[канал]) в ассемблерных
комментариях, поскольку он поддерживает Intel'евский и AT&amp;T синтаксисы, а
буква <literal>|</literal> &mdash; символ в Intel'евском варианте. Проблема
в том, что он <emphasis>молча</emphasis> игнорирует весь ассемблерный блок.
Теперь, это предположительно исправлено, GCC печатает предупреждение, а не
пропускает блок.
</para>

<formalpara>
<title>Текущее состояние:</title>
<para>
Red Hat заявляет, что GCC 2.96-85 и далее исправлены. Ситуация действительно
улучшилась, хотя мы всё ещё видим в рассылках сообщения о проблемах, которые
исчезают после перехода на другой компилятор. В любом случае, это больше не
важно. Предположительно готовый GCC 3.x должным образом разрешит эти вопросы.
Если Вы хотите скомпилировать, используя версию 2.96, укажите опцию <option>
--disable-gcc-checking</option> в <filename>configure</filename>. Помните, что
Вам решать, и <emphasis role="bold">не сообщайте об ошибках в этом случае</emphasis>.
Если Вы попробуете, Вы будете изгнаны из наших рассылок, поскольку у нас уже
было достаточно 'сражений' из-за GCC 2.96. Давайте оставим эту тему в покое.
</para>
</formalpara>

<para>
Если у Вас проблемы с GCC 2.96, Вы можете скачать 2.96-85 пакеты на
<ulink url="ftp://updates.redhat.com">ftp сервере</ulink>RedHat, или просто
перейти на 3.0.4 пакеты, предлагаемые начиная с версии 7.2. Вы также можете
использовать
<ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-11/">gcc-3.2.3-11 пакеты</ulink>
(неофициальные, но работают нормально) и поставить их совместно с gcc-2.96,
который у Вас стоит. <application>MPlayer</application> их обнаружит,
и будет использовать 3.2 вместо 2.96. Если Вы не хотите или не можете
использовать пакеты, вот как Вы можете
скомпилировать GCC 3 из исходного кода:
</para>

<procedure>
<step><para>
  Пойдите на страницу
  <ulink url="http://gcc.gnu.org/mirrors.html">GCC зеркал</ulink>
  и скачайте <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>,
  где XXX &mdash; это
  номер версии. Этот файл включает полноценный компилятор C, которого достаточно
  для <application>MPlayer</application>'а. Если Вы также хотите C++, Java или
  какие-нибудь другие дополнительные возможности GCC, Вам, возможно, больше
  подойдёт <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename>.
  </para></step>
<step><para>
  Распакуйте архив:
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  </para></step>
<step><para>
  В отличие от других программ GCC собирается не в каталоге с исходным кодом,
  а в отдельном каталоге. Поэтому вам нужно создать этот каталог, выполнив
  <screen>mkdir gcc-build</screen>
  </para></step>
<step><para>
  Теперь Вы можете приступить к конфигурированию gcc в каталоге для сборки, но
  Вам нужно конфигурировать из каталога с исходным кодом:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Скомпилируйте GCC, выполнив эту команду в каталоге для сборки:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Теперь Вы можете установить GCC (как root), выполнив
  <screen>make install</screen>
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Распространение в двоичном(скомпилированном) виде</title>

<para>
Прежде <application>MPlayer</application> содержал исходный код из проекта
OpenDivX, который не разрешал распространение в скомпилированном виде. Этот код
был изъят, начиная с версии 0.90-pre1, а остававшийся файл <filename>divx_vbr.c
</filename>, основывающийся на исходном коде OpenDivX, помещён под GPL его
авторами, начиная с версии 0.90pre9. Теперь Вы можете создавать
скомпилированные пакеты, если Вам захочется.
</para>

<para>
Другим препятствием к распространению в двоичном виде была оптимизация времени
компиляции под конкретную архитектуру процессора. Теперь <application>MPlayer
</application>поддерживает определение CPU во время выполнения (укажите
<command>configure</command>
опцию <option>--enable-runtime-cpudetection</option>). Это по умолчанию
выключено, поскольку это вызывает небольшую потерю в скорости, но зато теперь
возможно создавать бинарники, которые будут работать на разных CPU из семейства
Intel-совместимых.
</para>
</sect1>


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

<para>
Нам не нравится то, что <ulink url="http://www.nvidia.com">nVidia</ulink>
предоставляет только двоичные драйверы (для использования с XFree86), которые
часто бывают глючными. У нас было много сообщений в 
<ulink url="http://lists.mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
о проблемах, связанных с этими драйверами с закрытым исходным кодом, их плохим
качеством, нестабильностью и плохой поддержкой пользователей и специалистов.
Многие из этих проблем продолжают появляться снова и снова. Мы всегда
связывались после этого с nVidia, и они говорили, что эти ошибки не существуют,
что нестабильность вызывается плохими AGP чипами, и что они не получали
сообщений об ошибках в драйверах (таких, как пурпурная линия). Поэтому, если
у Вас проблема с nVidia картой, мы можем только посоветовать обновить nVidia
драйвер, и/или купить новую материнскую плату, или попросить nVidia предоставить
драйвер с открытым исходным кодом. В любом случае, если Вы используете двоичный
nVidia драйвер и столкнулись с проблемой, связанной с драйвером, знайте, что
Вы почти не получите помощи с нашей стороны, поскольку в этом случае у нас почти
нет возможности Вам помочь.
</para>
</sect1>


<sect1 id="joe-barr">
<title>Джо Барр[Joe Barr]</title>

<para>
Джо Барр получил дурную репутацию, после написания менее, чем благосклонного
обзора <application>MPlayer</application>'а, названного
<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: The project from hell[MPlayer: проект из ада]</ulink>.
Он счёл, что <application>MPlayer</application> сложно установить, и заявил,
что разработчики были недружелюбны, а документация неполной
и оскорбительной. Вам решать. Затем, он негативно упомянул Arpi в
<ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002[10 предсказаний о Linux на 2002]</ulink>.
В появившемся затем обзоре xine, названном
<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us[Потоковый проигрыватель фильмов для остальных]</ulink>
он продолжил раздувать спор. Иронично, но в конце этой статьи он цитирует
интервью с Гюнтером Барцхом[G&uuml;nter Bartsch], первоначальным автором <application>xine</application>,
которое превосходно подытоживает ситуацию:

<blockquote>
<para>
However, he also went on to say that he was &quot;surprised&quot; by my column about
<application>Mplayer</application> and thought it was unfair, reminding me that it is
a free software project. "If you don't like it," Bartsch said, "you're free not to use it."
</para>
<para>
[Однако, он также сказал, что он был &quot;удивлён&quot; моей колонкой
о <application>MPlayer</application>'е и
подумал, что это было бы неправильно напоминать мне, что это проект свободного
программного обеспечения. "Если он вам не нравится", сказал Барцх, "Вы свободны
не использовать его."]
</para>
</blockquote>

Спустя почти два года, в октябре 2003, он написал другой обзор, названный
Almost two years later in october 2003 he wrote another review called
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited[Снова MPlayer]</ulink>
(неправильное написание сохранено).
В этой статье он пришёл к таким заключениям:

<blockquote><para>
I would have to say that there have been improvements in the number of
features, in performance, and in documentation. It's still not the
easiest install in the world, especially for newbies, but it's a
little better than it used to be.
</para><para>
[Я должен сказать, что улучшения коснулись многих возможностей,
производительности и документации. Это всё ещё не простейшая в мире установка,
особенно для новичков, но это лучше, чем то, что было.]
</para></blockquote>

и

<blockquote><para>
But more importantly, I didn't notice any recent comments about user
abuse. I think I deserve some of the credit for that, even if I do say
so myself. Arpi and the rest of the project team must feel that way
too, because they have taken care to remember me in a special section
of the documentation included in the tarball. Like I said at the
start, some things haven't changed at all.
</para>
<para>
Но, что более важно, я не заметил никаких комментариев о пользовательской
ругани. Я полагаю, что я тоже заслуживаю похвалу за это, хотя мне и приходится
говорить это самому. Arpi и остальные из команды, наверное, тоже так думают,
поскольку они выделили мне специальную секцию в документации, включённой
в архив. Как я сказал вначале, некоторые вещи совсем не изменились.
</para></blockquote>

Мы бы не смогли лучше сформулировать наши чувства по отношению к Джо Барру:
&quot;
Это всё ещё не лучшая исследовательская статья в мире, но она лучше, чем была.]
[It's still not the fairest or best researched article in the world,
but it's better than it used to be.&quot; Надеемся, что в следующий раз
наши ожидания совпадут. Тем не менее, благодарность за зрелость относится только
к нашему увеличивающемуся возрасту, и, может быть, утомлению от от воин флейма.
</para>

</sect1>
</appendix>