Mercurial > mplayer.hg
view DOCS/Polish/users_against_developers.html @ 6110:7bea806b9c5f
Improvment for spu subtitles.
Removed the integreted spudec in vobsub.
Various cleanup/bugfix in vobsub (no more auto palette when a true one is
here)
HW spu rendering moved in spudec because we first need to reassable the
packet before sending them to the hw.
Spudec is now created only if nedded.
author | albeu |
---|---|
date | Fri, 17 May 2002 23:47:27 +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>