Mercurial > mplayer.hg
view DOCS/Polish/users_against_developers.html @ 8844:3f32b0a251ab
Report X color depth for XVIDIX problems.
Patch by James Stembridge <jstembridge@gmx.net>.
author | diego |
---|---|
date | Wed, 08 Jan 2003 19:59:46 +0000 |
parents | d5c692754cf2 |
children |
line wrap: on
line source
<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>