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

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- synced with 1.12 -->
<appendix id="users-vs-dev">
<title>Deweloperzy 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³ady to
<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> równie¿ ucierpia³ 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, ¿e 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 polega na tym, ¿e ca³y blok assemblera jest
<emphasis>po cichu</emphasis> ignorowany. 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
rzeczywi¶cie poprawi³a siê, ci±gle jednak dostajemy raporty o b³êdach na nasze
listy dyskusyjne, które znikaj± wraz z przej¶ciem na inny kompilator. W ka¿dym
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 dyskusyjnej, poniewa¿ mamy
ju¿ bardziej 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. <application>MPlayer</application> 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 mieæ 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³a z 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 ona 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 przyczyn± braku stabilno¶ci s± wadliwe uk³ady 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, radzimy zainstalowaæ najnowsz± wersjê
sterowników nVidia i/lub kupno nowej p³yty g³ównej lub poprosiæ nVidiê o otwarte
sterowniki. W ka¿dym 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 niezbyt pochlebn±
recenzjê <application>MPlayera</application> zatytu³owan±
<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: 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ñ. Nastêpnie
negatywnie pisa³ o Arpim 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 powiedzia³ te¿, ¿e by³ &quot;zaskoczony&quot; moim artyku³em o
<application>Mplayerze</application> i uwa¿a go za niesprawiedliwy,
przypominaj±c, ¿e jest to projekt wolnego oprogramowania. &quot;Je¶li Ci siê nie
podoba,&quot; powiedzia³ Bartsch, &quot;nie ma przeszkód, ¿eby¶ go nie u¿ywa³.&quot;
</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>
(umy¶lnie zachowana z³a pisownia).
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 tylko ja tak twierdzê.
Arpi i reszta zespo³u pracuj±cego nad projektem musz± uwa¿aæ tak samo, poniewa¿
zatroszczyli siê o wzmiankê o mnie w specjalnym rozdziale ich dokumentacji
do³±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>