path: root/DOCS/xml/pl/users-vs-dev.xml

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- synced with 1.10 -->
<appendix id="users-vs-dev">
<title>Developerzy wyrywaj± sobie w³osy</title>

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

<formalpara>
<title>Zarys historyczny:</title>
<para>
GCC z serii <emphasis role="bold">2.95</emphasis> jest oficjalnym wydaniem GNU,
a jego wersja 2.95.3 jest najbardziej wolna od b³êdów.  Nigdy nie odnotowali¶my
problemów przy kompilacji, które mogliby¶my przypisaæ gcc-2.95.3. Zaczynaj±c od 
Red Hat Linuksa 7.0, <emphasis role="bold">Red Hat</emphasis> do³±czy³ powa¿nie 
zmodyfikowan± wersjê CVS GCC do swojej dystrybucji i nazwa³ j± 
<emphasis role="bold">2.96</emphasis>. Sta³o siê tak, poniewa¿ GCC 3.0 
nie by³o jeszcze ukoñczone, a potrzebowano kompilatora, który wspó³dzia³a³by dobrze 
z wszystkimi platformami jakie by³y obs³ugiwane, w³±czaj±c w to IA64 i 
s390. Dystrybutor <emphasis role="bold">Mandrake</emphasis> równie¿ poszed³ w ¶lady 
Red Hata i zacz±³ do³±czaæ GCC 2.96 do serii Linux-Mandrake 8.0.
</para>
</formalpara>

<formalpara>
<title>O¶wiadczenie:</title>
<para>
Zespó³ GCC wypar³ siê jakichkolwiek powi±zañ z GCC 2.96 i wystosowa³
<ulink url="http://gcc.gnu.org/gcc-2.96.html">oficjaln± odpowied¼</ulink>
na GCC 2.96. Wielu developerów ze ¶wiata zaczê³o mieæ problemy z tym kompilatorem
i zarekomendowali inne. Przyk³adami s± 
<ulink url="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</ulink>
i
<ulink url="http://avifile.sourceforge.net/news-old1.htm">avifile</ulink>. 
Inne, interesuj±ce linki: 
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
 Krótka wiadomo¶æ o j±drze 2.4.17</ulink>
i
<ulink url="http://www.voy.com/3516/572.html">Forum Voy</ulink>.
<application>MPlayer</application> ucierpia³ równie¿ z powodu okresowych
problemów, które zosta³y rozwi±zane przez przesiadkê na inn± wersjê GCC. Kilka
projektów rozpoczê³o implementacjê obej¶æ dla pewnych spraw zwi±zanych z 2.96, 
ale my postanowili¶my nie naprawiaæ b³êdów innych, szczególnie je¿eli niektóre
obej¶cia mog± ujemnie wp³ywaæ na wydajno¶æ.
</para>
</formalpara>

<para>
GCC 2.96 nie pozwala na u¿ycie symbolu <literal>|</literal> (pipe - potok) w
komentarzu assemblera, poniewa¿ obs³uguje zarówno sk³adniê Intela jak i AT&amp;T, 
a symbol <literal>|</literal> jest stosowany w wariancie Intela. Problem le¿y w fakcie, ¿e
<emphasis>cicho</emphasis> ignoruje on ca³y blok assemblera. Rzekomo
zosta³o to ju¿ naprawione i GCC wy¶wietla ostrze¿enie zamiast pomijania tego bloku.
</para>

<formalpara>
<title>Tera¼niejszo¶æ:</title>
<para>
Red Hat twierdzi, ¿e GCC 2.96-85 i kolejne zosta³y ju¿ poprawione. Sytuacja, w rzeczy samej,
poprawi³a siê, ci±gle jednak dostajemy raporty o b³êdach na nasze listy mailingowe, które znikaj± 
wraz z przej¶ciem na inny kompilator. W ka¿dym b±d¼ razie, nie ma to ju¿ znaczenia. 
Mamy nadziejê, ¿e dojrzewaj±ce GCC 3.x na dobre zakoñczy tê sprawê.  Je¿eli chcesz 
kompilowaæ z 2.96, przeka¿ flagê <option>--disable-gcc-checking</option>
skryptowi <filename>configure</filename>. Pamiêtaj, ¿e mo¿esz wtedy liczyæ tylko na siebie i
<emphasis role="bold">nie zg³aszaj ¿adnych b³êdów</emphasis>. Je¿eli to zrobisz, zostanie
odebrany Ci dostêp do naszej listy mailingowej, poniewa¿ mamy ju¿ wiêcej ni¿ do¶æ bezsensownych k³ótni
na temat GCC 2.96. Proszê, zostaw tê sprawê w spokoju.
</para>
</formalpara>


<para>
Je¿eli masz problemy z GCC 2.96, mo¿esz pobraæ paczki 2.96-85 
z <ulink url="ftp://updates.redhat.com">serwera ftp</ulink> Red Hat lub 
skorzystaæ z pakietów 3.0.4, oferowanych z wersj± 7.2 i kolejnymi. Mo¿esz równie¿ ¶ci±gn±æ
<ulink url="ftp://people.redhat.com/jakub/gcc/3.2.3-11/">pakiety gcc-3.2.3-11</ulink>
(nieoficjalne, ale dzia³aj± dobrze)
i zainstalowaæ je razem z gcc-2.96, które ju¿ masz. MPlayer wykryje 
je i u¿yje 3.2 zamiast 2.96. Je¿eli nie chcesz albo nie mo¿esz u¿yæ binarnych 
paczek, poni¿ej znajdziesz informacje, jak skompilowaæ GCC 3 ze ¼róde³:
</para>

<procedure>
<step><para>
  Wejd¼ na stronê 
  z <ulink url="http://gcc.gnu.org/mirrors.html">serwerami lustrzanymi GCC</ulink>
  i ¶ci±gnij <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>,
  gdzie <replaceable>XXX</replaceable> to numer wersji. W pliku znajduje siê 
  kompletny kompilator C, który wystarczy dla <application>MPlayera</application>. 
  Je¿eli chcesz równie¿ C++, Java albo inne z zaawansowanych mo¿liwo¶ci GCC, 
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> mo¿e bardziej 
  pasowaæ do twoich potrzeb.
  </para></step>
<step><para>
  Rozpakuj archiwum, wykonuj±c
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  </para></step>
<step><para>
  GCC nie jest budowane w katalogu ¼ród³owym, jak wiêkszo¶æ programów,
  ale potrzebuje katalogu kompilacji poza katalogiem ze ¼ród³ami.  Bêdziesz musia³ 
  stworzyæ katalog przez 
  <screen>mkdir gcc-build</screen>
  </para></step>
<step><para>
  Dalej mo¿esz przej¶æ do procedury konfiguracyjnej i katalogu budowy, ale 
  musisz skonfigurowaæ z katalogu ¼ród³owego:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Skompiluj GCC, wykonuj±c tê komendê w katalogu kompilacji:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Teraz mo¿esz zainstalowaæ GCC (jako superu¿ytkownik), wpisuj±c
  <screen>make install</screen>
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Dystrybucja binariów</title>

<para>
<application>MPlayer</application> zawiera³ wcze¶niej ¼ród³o projektu 
OpenDivX, który zabrania redystrybucji binariów. Kod ten zosta³ usuniêty w wersji 
0.90-pre1, a pozostawiony plik <filename>divx_vbr.c</filename>, który pochodzi ze ¼róde³ 
OpenDivX, zosta³ objêty licencj± GPL przez jego autorów w wersji 0.90pre9. 
Mo¿esz teraz, bez obaw, tworzyæ pakiety binarne. 
</para>

<para>
Kolejn± przeszkod± przy redystrybucji binariów by³a optymalizacja dla konkretnej 
architektury CPU podczas kompilacji. <application>MPlayer</application> obs³uguje 
wykrywanie CPU podczas uruchamiania (podaj opcjê 
<option>--enable-runtime-cpudetection</option> dla skryptu <command>configure</command>). 
Jest domy¶lnie wy³±czona, poniewa¿ wymaga po¶wiêcenia ma³ej czê¶ci mocy obliczeniowej procesora. 
Jednak mo¿liwe jest teraz tworzenie binariów, które bêd± dzia³a³y na ró¿nych typach 
procesorów kompatybilnych z Intelem. 
</para>
</sect1>


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

<para>
Nie podoba nam siê fakt, ¿e <ulink url="http://www.nvidia.com">nVidia</ulink>
dostarcza wy³±cznie sterowniki binarne (dla XFree86), które czêsto zawieraj± b³êdy. 
Dostali¶my wiele zg³oszeñ na 
<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
o ich b³êdach, marnej jako¶ci, braku stabilno¶ci oraz 
s³abym wsparciu dla u¿ytkownika i eksperta.
Wiele z tych problemów/kwestii pojawia siê ci±gle. nVidia skontaktowa³a siê
z nami ostatnio i stwierdzi³a, ¿e te b³êdy nie istniej±, a brak stabilno¶ci
jest podyktowany wadliwymi chipami AGP, nie otrzymali równie¿ ¿adnych zg³oszeñ
o b³êdach w sterowniku (takich, jak purpurowa linia). Je¿eli masz problem ze swoj± kart± 
nVidia, doradzana jest Ci instalacja najnowszej wersji sterowników nVidia i/lub 
kupno nowej p³yty g³ównej lub poproszenie o otwarte sterowniki. W ka¿dym b±d¼ razie,
je¿eli u¿ywasz sterowników binarnych nVidia i stajesz przed problemami z nimi zwi±zanymi, 
b±d¼ ¶wiadom, ¿e nie otrzymasz zbyt du¿ej pomocy z naszej strony, poniewa¿ nie mamy 
du¿ej mo¿liwo¶ci jej udzielenia.
</para>
</sect1>


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


<para>
Joe Barr sta³ siê ma³o popularny w grudniu 2001, pisz±c mniej ni¿ pochlebn± 
recenzjê <application>MPlayera</application> zatytu³owan±
<ulink url="http://www.linuxworld.com/story/32880.htm">MPlayer: Projekt z piek³a rodem</ulink>. 
Mia³ problemy z jego instalacj±. Stwierdzi³ równie¿, ¿e developerzy byli ma³o przyja¼ni, 
a dokumentacja niekompletna i ubli¿aj±ca. Sam oceñ.
Dalej, negatywnie wspomnia³ o Arpi'm w swoich
<ulink url="http://www.linuxworld.com/story/32887.htm">10 prognozach dla Linuksa 
na rok 2002</ulink>.
W podobnej recenzji xine zatytu³owanej 
<ulink url="http://www.linuxworld.com/story/32716.htm">Strumieniowy odtwarzacz mediów dla reszty z nas</ulink>
ci±gle wzbudza³ kontrowersje. Jak na ironiê, pod koniec swojego artyku³u cytuje
krótk± wymianê zdañ miêdzy nim a Günterem Bartschem, twórc± <application>xine</application>,
która idealnie podsumowuje ca³± sprawê:

<blockquote><para>
Jednak¿e, mówi³ dalej, ¿e by³ "zdziwiony" moj± kolumn± o
<application>MPlayerze</application> i mówi³ mi, ¿e to niesprawiedliwe, przypominaj±c, ¿e 
jest to projekt wolnego oprogramowania. "Je¶li Ci siê nie podoba," powiedzia³ Bartsch, "nie ma przeszkód, ¿eby¶
go nie u¿ywa³."
</para></blockquote>
Prawie 2 lata pó¼niej w pa¼dzierniku 2003 napisa³ kolejn± recenzjê zatytu³owan± 
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer raz jeszcze</ulink>.
Zawarty jest w niej nastêpuj±cy wniosek:
 
<blockquote><para>
Muszê przyznaæ, ¿e znacznie zwiêkszy³a siê liczba mo¿liwo¶ci, poprawi³a siê wydajno¶æ 
i dokumentacja. Ci±gle instalacja nie jest naj³atwiejsza na ¶wiecie, szczególnie 
dla pocz±tkuj±cych, ale jest trochê lepiej ni¿ by³o.
</para></blockquote>

i

<blockquote><para>
Ale co najwa¿niejsze, nie dochodz± do mnie komentarze o oburzeniu u¿ytkowników. 
My¶lê, ¿e nale¿y mi siê za to uznanie, nawet je¿eli sobie tak wmawiam. 
Arpi i reszta zespo³u pracuj±cego nad projektem musz± czuæ to samo, poniewa¿
zatroszczyli siê i wspomnieli o mnie w specjalnym rozdziale ich dokumentacji 
za³±czonej w pliku tar. Jak mówi³em na pocz±tku, niektóre rzeczy siê nie  
zmieniaj±.
</para></blockquote>
 
Nie mo¿emy sprecyzowaæ naszego stanowiska wobec Joe Barr'a lepiej:
&quot;Ci±gle nie jest to najuczciwszy i najlepiej opracowany artyku³ 
na ¶wiecie, ale jest lepszy ni¿ kiedy¶.&quot; Mamy nadziejê, ¿e kiedy¶ przypadniemy 
sobie do gustu. Jednak uznanie za dojrza³o¶æ, mo¿emy tylko przypisaæ starzeniu siê 
i po czê¶ci zmêczeniu bezsensownymi k³ótniami.
</para>
</sect1>
</appendix>