diff options
Diffstat (limited to 'DOCS/xml/pl/users-vs-dev.xml')
| -rw-r--r-- | DOCS/xml/pl/users-vs-dev.xml | 228 |
1 files changed, 0 insertions, 228 deletions
diff --git a/DOCS/xml/pl/users-vs-dev.xml b/DOCS/xml/pl/users-vs-dev.xml deleted file mode 100644 index f2e5d33ec7..0000000000 --- a/DOCS/xml/pl/users-vs-dev.xml +++ /dev/null @@ -1,228 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-2"?> -<!-- synced with r15895 --> -<!-- Opiekun: brak (poprzednio Paszczi) --> -<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&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ł "zaskoczony" moim artykułem o -<application>Mplayerze</application> i uważa go za niesprawiedliwy, -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> -(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: -"Ciągle nie jest to najuczciwszy i najlepiej opracowany artykuł -na świecie, ale jest lepszy niż kiedyś." 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> |