Mercurial > mplayer.hg

<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>
author	diego
date	Sat, 08 Feb 2003 00:00:00 +0000
parents	DOCS/Polish/users_against_developers.html@d5c692754cf2
children	a07c2838fd28