view DOCS/xml/pl/users-vs-dev.xml @ 18715:30d7ddf08889

Fix window position when changing videos while in fullscreen and for window managers that modify position on Map. Oked by Alexander Strasser.
author reimar
date Thu, 15 Jun 2006 08:00:37 +0000
parents 14acc289b98b
children 87d755e003e7
line wrap: on
line source

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- synced with 1.17 -->
<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> (teraz Mandriva)
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 kilka projektów, między innymi
<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>
zaczęło rekomendować inne rozwiązania. 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/errata/3.2.3-37/">pakiety
gcc-3.2.3-37</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>