mirror of
https://github.com/mpv-player/mpv
synced 2024-12-22 23:02:37 +00:00
3687495972
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@4815 b3059339-0415-0410-9bf9-f77b7e298cf2
188 lines
9.4 KiB
HTML
188 lines
9.4 KiB
HTML
<HTML>
|
|
<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>
|