1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
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>
|
