view DOCS/xml/cs/users-vs-dev.xml @ 16484:5ad0e114d716

Typos
author gpoirier
date Wed, 14 Sep 2005 09:52:56 +0000
parents 7ba279f0afa0
children 3488e511e94b
line wrap: on
line source

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- Synced with: 1.16 -->
<appendix id="users-vs-dev">
<title>Nářky vývojářů</title>

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

<formalpara>
<title>Pozadí:</title>
<para>
GCC řady <emphasis role="bold">2.95</emphasis> je oficiální GNU vydání a
GCC verze 2.95.3 je nejméně chybovou verzí v sérii. Nikdy jsme nezaznamenali
kompilační problémy, které bychom vystopovali až ke gcc-2.95.3. Počínaje
Red Hat Linuxem 7.0, <emphasis role="bold">Red Hat</emphasis> zařadil silně
patchovanou CVS verzi GCC do své distribuce a pojmenoval ji
<emphasis role="bold">2.96</emphasis>. Red Hat tuto verzi zařadil do distribuce,
protože GCC 3.0 v té době nebylo dokončeno a potřebovali kompilátor, který by
dobře fungoval na všech jimi podporovaných platformách, včetně
IA64 a s390. Linuxový distributor <emphasis role="bold">Mandrake</emphasis>
rovněž následoval příkladu Red Hatu a začal zařazovat GCC 2.96 do jejich
řady Linux-Mandrake 8.0.
</para>
</formalpara>

<formalpara>
<title>Bilance:</title>
<para>
GCC tým odmítl jakoukoli spojitost s GCC 2.96 a vydal
<ulink url="http://gcc.gnu.org/gcc-2.96.html">officiální vyjádření</ulink>
ke GCC 2.96. Mnoho vývojářů na světě začalo mít problémy s
GCC 2.96 a několik projektů, mezi nimi i
<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>,
začalo doporučovat jiné kompilátory.
Další zajímavé odkazy jsou
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
Linux kernel news flash about kernel 2.4.17</ulink>
a
<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>.
Rovněž <application>MPlayer</application> trpěl občasnými problémy, které
byly všechny vyřešeny přechodem na jinou verzi GCC. Několik projektů
začalo implementovat "obchvaty" některých sporných míst 2.96, ale my
jsme odmítli opravovat chyby jiných lidí, zvlášť když některé obchvaty
mohou způsobit snížení výkonu.
</para>
</formalpara>

<para>
GCC 2.96 neumožňuje znaky <literal>|</literal> (roura) v assemblerových
komentářích, jelikož podporuje jak syntaxi Intel, tak AT&amp;T a znak
<literal>|</literal> je ve variantě Intel symbolem. Problém je, že
<emphasis>tiše</emphasis> ignoruje celý blok assembleru.
To je snad již opraveno, GCC vypíše varování místo přeskočení bloku.
</para>

<formalpara>
<title>Současnost:</title>
<para>
Red Hat říká, že GCC 2.96-85 a výš je opravený. Situace se mezi tím zlepšila.
Stále vidíme problémy v našich konferencích, které zmizí s jiným kompilátorem.
V mnoha případech na tom vůbec nezáleží. Doufáme, že dospívající GCC 3.x
odstraní tyto problémy nadobro. Pokud chcete kompilovat s 2.96 zadejte
volbu <option>--disable-gcc-checking</option> do
<filename>configure</filename>. Pamatujte však, že jste v tom sami,
<emphasis role="bold">nehlaste tedy žádné chyby</emphasis>. Pokud to uděláte,
budete vyločeni z naší konference, jelikož již máme dost dohadování se
(flame vars) ohledně GCC 2.96. Nechte to již prosíme být.
</para>
</formalpara>

<para>
Pokud máte problémy s GCC 2.96, můžete si opatřit balíčky 2.96-85 z
<ulink url="ftp://updates.redhat.com">ftp servru</ulink> Red Hatu, nebo použít
balíčky 3.0.4 nabízené od verze 7.2 a pozdějších. Rovněž si můžete opatřit
<ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">balíčky gcc-3.2.3-37</ulink>
(neofficiální, ale dobře fungující)
a můžete je nainstalovat paralelně ke gcc-2.96, kterou již máte.
<application>MPlayer</application> to zdetekuje a použije 3.2 místo 2.96.
Pokud nechcete, nebo nemůžete použít binární balíčky, takto můžete zkompilovat
GCC 3 ze zdrojových kódů:
</para>

<procedure>
<step><para>
  Běžte na
  <ulink url="http://gcc.gnu.org/mirrors.html">stránku zrcadel GCC</ulink>
  a stáhněte si <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>,
  kde <replaceable>XXX</replaceable> je číslo verze. Archiv obsahuje úplný
  kompilátor C a pro <application>MPlayer</application> je dostatečný. Pokud
  chcete i C++, Javu nebo některou jinou pokročilou vlastnost GCC,
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> vám bude
  vyhovovat lépe.
  </para></step>
<step><para>
  Rozbalte archiv příkazem
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  </para></step>
<step><para>
  GCC není sestavováno do adresáře se zdrojovými kódy jako většina jiných
  programů, ale vyžaduje adresář mimo adresáře s kódy. Proto musíte
  tento adresář vytvořit pomocí
  <screen>mkdir gcc-build</screen>
  </para></step>
<step><para>
  Pak můžete přistoupit ke konfiguraci gcc v sestavovacím adresáři, ale
  potřebujete configure ze zdrojového adresáře:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Zkompilujte GCC spuštěním tohoto příkazu v sestavovacím adresáři:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Nyní můžete nainstalovat GCC (jako root) zadáním
  <screen>make install</screen>
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Binární distribuce</title>

<para>
<application>MPlayer</application> dříve obsahoval zdrojový kód z projektu
OpenDivX, který znemožňoval binární distribuci. Tento kód byl od verze 0.90-pre1
odstraněn a zbývající soubor <filename>divx_vbr.c</filename>, který je odvozen
ze zdrojových kódů OpenDivX byl svými autory vydán pod licencí GPL okolo verze
0.90pre9. Nyní si můžete vytvořit binární balíčky podle své chuti.
</para>

<para>
Další překážkou v binární redistribuci byly optimalizace pro CPU architekturu
při kompilaci. <application>MPlayer</application> nyní podporuje detekci
CPU za běhu (zadejte volbu
<option>--enable-runtime-cpudetection</option> do <command>configure</command>).
Tato vlastnost je ve výchozím nastavení vypnuta, jelikož způsobuje malé snížení
rychlosti, ale umožňuje vytvářet binárky, které poběží na různých zástupcích
Intel kompatibilních procesorů.
</para>
</sect1>


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

<para>
Nelíbí se nám, že <ulink url="http://www.nvidia.com">nVidia</ulink>
poskytuje pouze binární ovladače (pro použití s XFree86), které jsou často
chybné.
Máme mnoho hlášení o problémech s těmito ovladači v
<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
a jejich malé kvalitě, nestabilitě a slabé uživatelské a expertní podpoře.
Mnoho z těchto problémů/chyb se neustále opakují.
Později jsme byli kontaktováni nVidií a řekli nám, že tyto chyby neexistují,
nestabilita je způsobena špatnými AGP čipy a oni nemají žádná hlášení o chybách
ovladačů (jako je fialová čára). Takže pokud máte problémy se svou nVidia
kartou, doporučujeme aktualizovat ovladač a/nebo si koupit nový
motherboard, nebo požádat nVidii o dodání open-source ovladačů. V každém případě,
pokud používáte binární ovladače od nVidie a máte problémy ve vztahu k ovladači,
počítejte prosím s tím, že se vám dostane z naší strany jen malé pomoci,
jelikož v tomto případě máme omezené možnosti.
</para>
</sect1>


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

<para>
Joe Barr se stal neblaze proslulým v prosinci 2001 napsáním tvrdé(?)
recenze <application>MPlayer</application>u nazvané
<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: Project z pekla</ulink>.
Shledal <application>MPlayer</application> těžko instalovatelným a usoudil,
že vývojáři byli nepřátelští a dokumentace neúplná a urážlivá.
Posuďte však sami.
Negativně se zmínil o Arpim v článku
<ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>.
V následující recenzi xine nazvané
<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink>
pak pokračoval v kontroverzní polemice. Ironií je, že na konci tohoto článku
citoval svou výměnu názorů s Günterem Bartschem, původním autorem
<application>xine</application>, která perfektně shrnuje celou situaci:

<blockquote><para>
Ačkoli mi rovněž řekl, že byl &quot;překvapen&quot; mým sloupkem o
<application>Mplayer</application>u a myslí si, že je nefér, připomenul mi,
že je to svobodný softwarový projekt. &quot;Když se vám nelíbí,&quot;
řekl Bartsch, &quot;můžete jej svobodně nepoužívat.&quot;
</para></blockquote>

Téměř o dva roky později v říjnu 2003 napsal další recenzi nazvanou
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink>
(chyby v gramatice vyhrazeny).
Ve ketré uvedl následující závěry:

<blockquote><para>
Je třeba říct, že jsou zde vylepšení v počtu vlastností, ve výkonu
a v dokumentaci. Stále to není nejlehčí instalace na světě, zvláště pro
nováčky, ale je to lepší, než to bylo.
</para></blockquote>

a

<blockquote><para>
Ale mnohem důležitější je, že jsem si zde nepovšiml žádných aktuálních
komentářů o urážení uživatelů. Myslím, že je to i moje zásluha, dokonce
i když to říkám sám o sobě. Arpi a zbytek vývojářů to museli cítit také tak,
jelikož si dali práci, aby mě zmínili ve zvláštní sekci dokumentace
obsažené v tarbalu. Jak jsem řekl na začátku, něktré věci se nezměnily.
</para></blockquote>

Naše pocity k Joe Barrovi nemůžeme shrnout lépe než:
&quot;Stále to není nejférovější nebo nejfundovanější článek na světě,
ale je lepší než předtím.&quot; Doufáme, že příště si vzájemně splníme
svá očekávání. Zásluhu za naši vyspělost má výhradně náš vyšší věk a možná
únava z flame wars.
</para>

</sect1>
</appendix>