diff options
Diffstat (limited to 'DOCS/pl/users_against_developers.html')
| -rw-r--r-- | DOCS/pl/users_against_developers.html | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/DOCS/pl/users_against_developers.html b/DOCS/pl/users_against_developers.html new file mode 100644 index 0000000000..a2f2af8d35 --- /dev/null +++ b/DOCS/pl/users_against_developers.html @@ -0,0 +1,192 @@ +<HTML> + +<HEAD> + <META http-equiv="content-type" content="text/html; charset=iso-8859-2" /> +</HEAD> + +<BODY BGCOLOR=white> + +<FONT face="Verdana, Arial, Helvetica, sans-serif" size=2> + +<P><B><I>In medias res</I></B></P> + +<P>Są takie dwa tematy, które zawsze wywołują wielką dyskusję i ogniste boje na +liście dyskusyjnej <A +HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">użytkowników mplayera</A>. +Tematem numer jeden jest:</P> + +<A NAME=gcc><P><B><I>serie GCC 2.96</I></B></P> + +<P><B>Przeczytaj też <A HREF="gcc-2.96-3.0.html">ten</A> tekst !!!</B></P> + +<P><I>Tło</I>: były/są serie GCC <B>2.95</B>. Najlepszą z nich była 2.95.3. +Zwróć uwagę na sposób numerowania wersji jądra. Oto jak drużyna GCC numeruje +swoje kompilatory. Serie 2.95 są dobre. Nigdy nie widziano, aby coś źle się +skompilowało z przyczyny błędów w 2.95.</P> + +<P><I>Poczynania</I>: <B>RedHat</B> rozpoczął włączanie wersji GCC <B>2.96</B> +w swoich dystrybucjach. Zwróć uwagę na numerację wersji. To powinno być +numerowanie drużyny GCC. Oni nałożyli łatę na wersję CVS GCC (coś na +pograniczu 2.95 a 3.0). Ta łata była bardzo poważna i tej werji użyto do +dystrybucji, ponieważ wersja 3.0 nie była skończona na czas, a oni chcieli mieć +obsługę IA64 ASAP (z powodów własnych interesów). A przecież GCC 2.95 +źle kompiluje bash na architekturze s390 (nie ma dystrybucji RedHata dla +s390..).</P> + +<P><I>Fakty</I>: proces kompilacji <B>MPlayera</B> wymaga +<CODE>--disable-gcc-checking</CODE>, aby pominąć wykrywanie wersji GCC 2.96 +(wyraźnie wymagana jest ta opcja przy <B>egcs</B> również; to dlatego, że my +nie testujemy <B>MPlayera</B> na egcs. Proszę nam wybaczyć, ale my raczej +zajmujemy się rozwijaniem <B>MPlayera</B>). Jeżeli znasz <B>MPlayera</B>, +powinieneś wiedzieć, że jest on bardzo szybki. Osiąga to poprzez +zoptymalizowanie kodu dla MMX/SSE/3DNow/itp., dzięki fastmemcpy i wielu innym +właściwościom. <B>MPlayer</B> zawierał instrujkcje MMX/3DNow w składni, którą +wszystkie kompilatory Linuksowe akceptują ... za wyjątkiem GCC RedHata (to +określenie jest bardziej zgodne ze standardem). On po prostu je +<B><I>przeskakuje</I></B>. Nie zgłasza błędów. Nie wysyła ostrzeżeń. <B>I</B>, +tam jest "Lame". Z gcc 2.96, sprawdzanie jakości (<CODE>make test</CODE> po +kompilacji) <I>nawet się nie uruchamia!!!</I> Hej, ale on kompiluje bash na +s390 i IA64.</P> + +<P><I>Wnioski</I>: większość developerów na świecie zaczęło mieć złe odczucia +w związku z GCC 2.96 RedHata. Powiedzieli oni swoim użytkownikom RedHat'a, aby +używali do kompilacji innych kompilatorów, niż 2.96. Rozczarowanie użytkowników +RedHata powoli przemieniło się w gniew. Co było takiego dobrego, w +przeciwieństwie do bólu głowy developerów, w dolewaniu oliwy do +anty-RedHatowskiego ognia, wprawiającym użytkowników w konsternację? Ja nie +znam odpowiedzi na to pytanie.</P> + +<P><I>Teraźniejszość</I>: RedHat twierdzi, że GCC 2.96-85 i kolejne wersje są +naprawione i pracują właściwie. Zwróć uwagę na numerację wersji.To typowe, że +zaczęli z czymś takim. A co z GCC 2.96.85? Nieistotne. Nie szukam, ale +wciąż widzę błędy w 2.96. To jest bez znaczenia teraz, miejmy nadzieję, że +<B>RedHat zapomni o 2.96</B> i skieruje się ku <B>3.0</B>. W kierunku +porządnie załatanego 3.0...</P> + +<P><I>To, czego ja tu nie rozumiem</I>, to z jakiego powodu jesteśmy oblegani +przez użytkowników RedHata, żalących się na komunikaty ostrzegawcze i dokumenty +w rodzaju "trzymaj się z dala" w <B>MPlayerze</B>. Dlaczego jesteśmy nazywani +"umysłowo upośledzonymi", "totalnymi dupkami", "dziecinnymi w swoim myśleniu" +przez <B>użytkowników RedHata</B>, na naszej mailowej liście dyskusyjnej, a +nawet na liście <B>redhat-devel</B>. Rozważali oni nawet stworzenie odgałęzienia +<B>MPlayera</B> dla nich samych. Użytkownicy RedHata. Dlaczego? Czy to RedHat +stworzył kompilator, dlaczego <U>wy</U> musicie nas nienawidzieć? Jesteście aż +<U>takimi</U> wyznawcami RedHata? Proszę, przestańcie. My nie chowamy +urazy do użytkowników, nie ważne jak głośno ogłaszacie coś przeciwnego. Idźcie, +proszę, użerać się z Linusem Torvaldsem, z developerami DRI (och, teraz wiem już +dlaczego oni zostali opuszczeni przez VA!), Wine, avifile. Jeśli nawet +jesteśmy aroganccy, czy nie jesteśmy tacy sami jak wcześniej wspomniani? +Dlaczego to <B>my</B> musimy cierpieć z powodu niesłusznego gniewu?</P> + +<P><A HREF="mailto:willis_matthew@yahoo.com">Matt Willis</A> uprzejmie +dostarczył proste howto (jak to zrobić) kompilacji GCC-3.0.3, które poniżej +zamieszczam:</P> + +<P> +<UL> + <LI>Ściągnij gcc. Idź na stronę: <A + HREF="http://gcc.gnu.org/mirrors.html">http://gcc.gnu.org/mirrors.html</A>. + Ja ściągnąłem następujące pliki, ale ty nie potrzebujesz ich wszystkich:<BR> + <CODE>gcc-g++-3.0.3.tar.gz<BR> + gcc-objc-3.0.3.tar.gz<BR> + gcc-3.0.3.tar.gz<BR> + gcc-g77-3.0.3.tar.gz<BR> + gcc-testsuite-3.0.3.tar.gz<BR> + gcc-core-3.0.3.tar.gz<BR> + gcc-java-3.0.3.tar.gz</CODE> + </LI> + + <LI>Rozpakuj pliki, stwórz katalog w którym będizesz budował i zbuduj: + <CODE><PRE> + tar xvzf gcc-*3.0.3.tar.gz + mkdir gcc-build; cd gcc-build + ../gcc-3.0.3/configure --prefix=/opt --program-suffix=-3.0.3 + make bootstrap; mkdir -p /opt; make install</PRE></CODE> + + <LI>Ustaw swoją ścieżkę, aby zawierała /opt/bin<BR> + <CODE>export PATH=/opt/bin:${PATH}</CODE> + + <LI>Teraz możesz budować MPlayera.</LI> +</UL> +</P> + +<A NAME=binary><P><B><I>Dystrybucja MPlayera w postaci binariów</I></B></P> + +<P>Tony użytkowników proszą nas o to. Na przykład użytkownicy Debiana maja +zwyczaj mówić: Oh, mogę zrobić <CODE>apt-get install avifile</CODE>, dlaczego +mam <B>kompilować MPlayera</B>? To brzmi rozsądnie, ale problem leży nieco +głębiej, niż: +ci-pieprzeni-developerzy-MPlayera-nienawidzą-gcc-2.96-i-RedHata-i-Debiana.</P> + +<P>Przyczyny: <B>Prawo</B></P> + +<P><B>MPlayer</B> zapisany jest jako <U>źródła</U>. Zawiera on kilka plików z +niekompatybilnymi liecencjami w punktach dotyczących redystrybucji. Jako +źródłowe pliki, mają one prawo współistnieć w tym samym projekcie.</P> + +<P>Jednakże <U>ANI BINARIA, ANI BINARNE PAKIETY <B>MPlayera</B> NIE MAJĄ PRAWA +ISTNIEĆ W CHWILI, GDY TAKIE OBIEKTY ŁAMIĄ LICENCJE</U>. LUDZIE, KTÓRZY +ROZPROWADZAJĄ TAKIE PAKIETY BINARNE POSTĘPUJĄ NIELEGALNIE.</P> + +<P>Więc jeśli znasz kogoś, kto rozporządza binarnymi pakietami, wówczas daj mu +do przeczytania ten tekst i (poproś go o) kontakt z nami. To co on/ona robi, +jest nielegalne I TO JUŻ NIE JEST <B>MPlayer</B>, a <U>jego/jej</U> mplayer. +Jeśli źle działa, to to jest jego/jej wina. Niech nikt nie przychodzi i nie +żali się na listę mailową <B>MPlayera</B>, bo najprawdopodobniej zostanie +zapisany na czarną listę.</P> + +<P>Przyczyny: <B>Techniczne</B></P> + +<P> +<UL> + <LI>Optymalizacja szybkości działania <B>MPlayera</B> (MMX, SSE, fastmemcpy, + itp) jest zdeterminowana podczas kompilacji. Z tego powodu skompilowane + binaria zawierają bardzo specyficzny dla danego procesora kod. Binaria + <B>MPlayera</B> skompilowane dla K6 nie będą wydolne na procesorach Pentium + i vice versa. To zostało rozpracowane poprzez wykrywanie runtime, co nie + jest łatwą do obejścia zrobienia, gdyż sprawia masową utratę prędkości. + Jeśli nie wierzysz (to było juz 10000 razy wyjaśnione w szczegółach na + mplayer-users, przeszukaj archiwum), to rozwikłaj to i wyślij nam patch. + Ktoś zaczął nad tym pracować, ale nie ma o nim wieści od tamtej pory.</LI> + <LI>System audio/video <B>MPlayera</B> nie jest oparty na systemie + wtyczek. System audio/video jest wkompilowany w binaria, co powoduje + zależność binariów od różnych bibliotek (GUI zależy od GTK, DivX4 zależy od + libdivxdecore, SDL zależy od libSDL, każde wydanie SDL zawiera unikalny + błąd, ktory musi być ominięty w czasie kompilacji, X11 wyjście w różny + sposób się kompiluje X3 i X4, itp). Możesz powiedzieć: więc zróbmy 30 + wersji binariów do ściągnięcia! Nie zrobimy tego. Zrobimy te rzeczy w + postaci wtyczek w przyszłości.</LI> +</UL> + +<A NAME=nvidia><P><B><I>NVidia</I></B></P> + +<P>Nie lubimy binarnych sterowników nvidii, ich jakości, niestabilności, +nieistniejącego wsparcia dla użytkowników, wciąż pojawiających się nowych +błędów. Większość użytkowników ma do nich podobne podejście. Skontaktowali się +z nami później ludzie z NVidii i powiedzieli, że te błędy nie istnieją, +niestabilność jest winą chipów AGP i odmówili opublikowania raportu o +błędach sterownika (np. o fioletowej linii). Więc jeśli masz problem ze swoją +NVidią, uaktualizuj sterownik nvidii i/lub kup nową płytę główną.</P> + +<A NAME=kotsog><P><B><I>Joe Barr</I></B></P> + +<P>On nie odpowiada na nasze maile. Jego wydawca nie odpowiada na nasze maile. +Sieć jest pełna jego fałszywych stwierdzeń i oskarżeń (on widocznie nei lubi na +przykład chłopaków z BSD, z powodu różnicy poglądów [na jaki temat?]).</P> + +<P>Oto kilka cytatów wypowiedzi różnych ludzi na temat Joe Barr (tylko po to, +abyś zrozumiał, dlaczego on się kompletnie nie liczy):</P> + +<P><I>"Wszyscy pamiętacie LinuxWorld 2000, kiedy on twierdził, że Linus T. +powiedział, że FreeBSD, to garstka developerów. Linus nie powiedział NICZEGO w +tym rodzaju. Kiedy to wypomniano Joe'mu, jego reakcją było wyzwanie ludzi +utrzymujących BSD of dupków i glupków."</I></P> + +<P><I>"On jest interesujący, ale kiepsko mu wychodzi unikanie ... +kontrowersyjności. Joe Barr był regularnym uczestnikiem forum Willa Zachmanna +w Compuserve, kilka lat temu. Był zwolennikiem OS/2 (ja również byłem +zwolennikiem OS/2). Często przekraczał wszelkie granice, rozwścieczając ludzi +i podejrzewam, że to były ciężkie czasy dla niego. Trochę złagodniał ostatnio, +będąc ocenionym przez własny dział redakcyjny. Stonowany, subtelny humor nie był +jednak jesgo stylem w tamtych wczesnych dniach w zupełności. "</I></P> +</HTML> |