summaryrefslogtreecommitdiffstats
path: root/DOCS/xml/pl/users-vs-dev.xml
blob: e0e6ae428fcde304d431367c09290e4ac7a35c25 (plain)
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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
<?xml version="1.0" encoding="iso-8859-2"?>
<!-- synced with 1.10 -->
<appendix id="users-vs-dev">
<title>Developerzy wyrywaj± sobie w³osy</title>

<sect1 id="gcc-296">
<title>GCC 2.96</title>

<formalpara>
<title>Zarys historyczny:</title>
<para>
GCC z serii <emphasis role="bold">2.95</emphasis> jest oficjalnym wydaniem GNU,
a jego wersja 2.95.3 jest najbardziej wolna od b³êdów.  Nigdy nie odnotowali¶my
problemów przy kompilacji, które mogliby¶my przypisaæ gcc-2.95.3. Zaczynaj±c od 
Red Hat Linuksa 7.0, <emphasis role="bold">Red Hat</emphasis> do³±czy³ powa¿nie 
zmodyfikowan± wersjê CVS GCC do swojej dystrybucji i nazwa³ j± 
<emphasis role="bold">2.96</emphasis>. Sta³o siê tak, poniewa¿ GCC 3.0 
nie by³o jeszcze ukoñczone, a potrzebowano kompilatora, który wspó³dzia³a³by dobrze 
z wszystkimi platformami jakie by³y obs³ugiwane, w³±czaj±c w to IA64 i 
s390. Dystrybutor <emphasis role="bold">Mandrake</emphasis> równie¿ poszed³ w ¶lady 
Red Hata i zacz±³ do³±czaæ GCC 2.96 do serii Linux-Mandrake 8.0.
</para>
</formalpara>

<formalpara>
<title>O¶wiadczenie:</title>
<para>
Zespó³ GCC wypar³ siê jakichkolwiek powi±zañ z GCC 2.96 i wystosowa³
<ulink url="http://gcc.gnu.org/gcc-2.96.html">oficjaln± odpowied¼</ulink>
na GCC 2.96. Wielu developerów ze ¶wiata zaczê³o mieæ problemy z tym kompilatorem
i zarekomendowali inne. Przyk³ady to
<ulink url="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</ulink>
i
<ulink url="http://avifile.sourceforge.net/news-old1.htm">avifile</ulink>. 
Inne interesuj±ce linki: 
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
 Krótka wiadomo¶æ o j±drze 2.4.17</ulink>
i
<ulink url="http://www.voy.com/3516/572.html">Forum Voy</ulink>.
<application>MPlayer</application> równie¿ ucierpia³ z powodu okresowych
problemów, które zosta³y rozwi±zane przez przesiadkê na inn± wersjê GCC. Kilka
projektów rozpoczê³o implementacjê obej¶æ dla pewnych spraw zwi±zanych z 2.96, 
ale my postanowili¶my nie naprawiaæ b³êdów innych, szczególnie, ¿e niektóre
obej¶cia mog± ujemnie wp³ywaæ na wydajno¶æ.
</para>
</formalpara>

<para>
GCC 2.96 nie pozwala na u¿ycie symbolu <literal>|</literal> (pipe - potok) w
komentarzu assemblera, poniewa¿ obs³uguje zarówno sk³adniê Intela jak i AT&amp;T, 
a symbol <literal>|</literal> jest stosowany w wariancie Intela. Problem polega na tym, ¿e
ca³y blok assemblera jest <emphasis>po cichu</emphasis> ignorowany. Rzekomo
zosta³o to ju¿ naprawione i GCC wy¶wietla ostrze¿enie zamiast pomijania tego bloku.
</para>

<formalpara>
<title>Tera¼niejszo¶æ:</title>
<para>
Red Hat twierdzi, ¿e GCC 2.96-85 i kolejne zosta³y ju¿ poprawione. Sytuacja rzeczywi¶cie
poprawi³a siê, ci±gle jednak dostajemy raporty o b³êdach na nasze listy mailingowe, które znikaj± 
wraz z przej¶ciem na inny kompilator. W ka¿dym razie, nie ma to ju¿ znaczenia. 
Mamy nadziejê, ¿e dojrzewaj±ce GCC 3.x na dobre zakoñczy tê sprawê.  Je¿eli chcesz 
kompilowaæ z 2.96, przeka¿ flagê <option>--disable-gcc-checking</option>
skryptowi <filename>configure</filename>. Pamiêtaj, ¿e mo¿esz wtedy liczyæ tylko na siebie i
<emphasis role="bold">nie zg³aszaj ¿adnych b³êdów</emphasis>. Je¿eli to zrobisz, zostanie
odebrany Ci dostêp do naszej listy mailingowej, poniewa¿ mamy ju¿ bardziej ni¿ do¶æ bezsensownych k³ótni
na temat GCC 2.96. Proszê, zostaw tê sprawê w spokoju.
</para>
</formalpara>


<para>
Je¿eli masz problemy z GCC 2.96, mo¿esz pobraæ paczki 2.96-85 
z <ulink url="ftp://updates.redhat.com">serwera ftp</ulink> Red Hat lub 
skorzystaæ z pakietów 3.0.4, oferowanych z wersj± 7.2 i kolejnymi. Mo¿esz równie¿ ¶ci±gn±æ
<ulink url="ftp://people.redhat.com/jakub/gcc/3.2.3-11/">pakiety gcc-3.2.3-11</ulink>
(nieoficjalne, ale dzia³aj± dobrze)
i zainstalowaæ je razem z gcc-2.96, które ju¿ masz. MPlayer wykryje 
je i u¿yje 3.2 zamiast 2.96. Je¿eli nie chcesz albo nie mo¿esz u¿yæ binarnych 
paczek, poni¿ej znajdziesz informacje, jak skompilowaæ GCC 3 ze ¼róde³:
</para>

<procedure>
<step><para>
  Wejd¼ na stronê 
  z <ulink url="http://gcc.gnu.org/mirrors.html">serwerami lustrzanymi GCC</ulink>
  i ¶ci±gnij <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>,
  gdzie <replaceable>XXX</replaceable> to numer wersji. W pliku znajduje siê 
  kompletny kompilator C, który wystarczy dla <application>MPlayera</application>. 
  Je¿eli chcesz mieæ równie¿ C++, Java albo inne z zaawansowanych mo¿liwo¶ci GCC, 
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> mo¿e bardziej 
  pasowaæ do twoich potrzeb.
  </para></step>
<step><para>
  Rozpakuj archiwum, wykonuj±c
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  </para></step>
<step><para>
  GCC nie jest budowane w katalogu ¼ród³owym, jak wiêkszo¶æ programów,
  ale potrzebuje katalogu kompilacji poza katalogiem ze ¼ród³ami.  Bêdziesz musia³ 
  stworzyæ katalog przez 
  <screen>mkdir gcc-build</screen>
  </para></step>
<step><para>
  Dalej mo¿esz przej¶æ do procedury konfiguracyjnej i katalogu budowy, ale 
  musisz skonfigurowaæ z katalogu ¼ród³owego:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Skompiluj GCC, wykonuj±c tê komendê w katalogu kompilacji:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Teraz mo¿esz zainstalowaæ GCC (jako superu¿ytkownik), wpisuj±c
  <screen>make install</screen>
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Dystrybucja binariów</title>

<para>
<application>MPlayer</application> zawiera³ wcze¶niej ¼ród³a z projektu 
OpenDivX, który zabrania redystrybucji binariów. Kod ten zosta³ usuniêty w wersji 
0.90-pre1, a pozostawiony plik <filename>divx_vbr.c</filename>, który pochodzi ze ¼róde³ 
OpenDivX, zosta³ objêty licencj± GPL przez jego autorów w wersji 0.90pre9. 
Mo¿esz teraz bez obaw tworzyæ pakiety binarne. 
</para>

<para>
Kolejn± przeszkod± przy redystrybucji binariów by³a optymalizacja dla konkretnej 
architektury CPU podczas kompilacji. <application>MPlayer</application> obs³uguje 
wykrywanie CPU podczas uruchamiania (podaj opcjê 
<option>--enable-runtime-cpudetection</option> dla skryptu <command>configure</command>). 
Jest ona domy¶lnie wy³±czona, poniewa¿ wymaga po¶wiêcenia ma³ej czê¶ci mocy obliczeniowej procesora.
Jednak mo¿liwe jest teraz tworzenie binariów, które bêd± dzia³a³y na ró¿nych typach 
procesorów kompatybilnych z Intelem. 
</para>
</sect1>


<sect1 id="nvidia-opinions">
<title>nVidia</title>

<para>
Nie podoba nam siê fakt, ¿e <ulink url="http://www.nvidia.com">nVidia</ulink>
dostarcza wy³±cznie sterowniki binarne (dla XFree86), które czêsto zawieraj± b³êdy. 
Dostali¶my wiele zg³oszeñ na 
<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
o ich b³êdach, marnej jako¶ci, braku stabilno¶ci oraz 
s³abym wsparciu dla u¿ytkownika i eksperta.
Wiele z tych problemów/kwestii pojawia siê ci±gle. nVidia skontaktowa³a siê
z nami ostatnio i stwierdzi³a, ¿e te b³êdy nie istniej±, a brak stabilno¶ci
jest podyktowany wadliwymi chipami AGP, nie otrzymali równie¿ ¿adnych zg³oszeñ
o b³êdach w sterowniku (takich, jak purpurowa linia). Je¿eli masz problem ze swoj± kart± 
nVidia, radzimy zainstalowaæ najnowsz± wersjê sterowników nVidia i/lub 
kupno nowej p³yty g³ównej lub poprosiæ nVidiê o otwarte sterowniki. W ka¿dym razie,
je¿eli u¿ywasz sterowników binarnych nVidia i stajesz przed problemami z nimi zwi±zanymi, 
b±d¼ ¶wiadom, ¿e nie otrzymasz zbyt du¿ej pomocy z naszej strony, poniewa¿ nie mamy 
du¿ej mo¿liwo¶ci jej udzielenia.
</para>
</sect1>


<sect1 id="joe-barr">
<title>Joe Barr</title>


<para>
Joe Barr sta³ siê ma³o popularny w grudniu 2001, pisz±c niezbyt pochlebn± 
recenzjê <application>MPlayera</application> zatytu³owan±
<ulink url="http://www.linuxworld.com/story/32880.htm">MPlayer: Projekt z piek³a rodem</ulink>. 
Mia³ problemy z jego instalacj±. Stwierdzi³ równie¿, ¿e developerzy byli ma³o przyja¼ni, 
a dokumentacja niekompletna i ubli¿aj±ca. Sam oceñ.
Nastêpnie negatywnie pisa³ o Arpim w swoich
<ulink url="http://www.linuxworld.com/story/32887.htm">10 prognozach dla Linuksa 
na rok 2002</ulink>.
W podobnej recenzji xine zatytu³owanej 
<ulink url="http://www.linuxworld.com/story/32716.htm">Strumieniowy odtwarzacz mediów dla reszty z nas</ulink>
ci±gle wzbudza³ kontrowersje. Jak na ironiê, pod koniec swojego artyku³u cytuje
krótk± wymianê zdañ miêdzy nim a Günterem Bartschem, twórc± <application>xine</application>,
która idealnie podsumowuje ca³± sprawê:

<blockquote><para>
Jednak powiedzia³ te¿, ¿e by³ "zaskoczony" moim artyku³em o
<application>MPlayerze</application> i uwa¿a go za niesprawiedliwy, przypominaj±c, ¿e 
jest to projekt wolnego oprogramowania. "Je¶li Ci siê nie podoba," powiedzia³ Bartsch, "nie ma przeszkód, ¿eby¶
go nie u¿ywa³."
</para></blockquote>
Prawie 2 lata pó¼niej w pa¼dzierniku 2003 napisa³ kolejn± recenzjê zatytu³owan± 
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer raz jeszcze</ulink>.
Zawarty jest w niej nastêpuj±cy wniosek:
 
<blockquote><para>
Muszê przyznaæ, ¿e znacznie zwiêkszy³a siê liczba mo¿liwo¶ci, poprawi³a siê wydajno¶æ 
i dokumentacja. Ci±gle instalacja nie jest naj³atwiejsza na ¶wiecie, szczególnie 
dla pocz±tkuj±cych, ale jest trochê lepiej ni¿ by³o.
</para></blockquote>

i

<blockquote><para>
Ale co najwa¿niejsze, nie dochodz± do mnie komentarze o oburzeniu u¿ytkowników. 
My¶lê, ¿e nale¿y mi siê za to uznanie, nawet je¿eli tylko ja tak twierdzê.
Arpi i reszta zespo³u pracuj±cego nad projektem musz± uwa¿aæ tak samo, poniewa¿
zatroszczyli siê o wzmiankê o mnie w specjalnym rozdziale ich dokumentacji 
do³±czonej w pliku tar. Jak mówi³em na pocz±tku, niektóre rzeczy siê nie  
zmieniaj±.
</para></blockquote>
 
Nie mo¿emy sprecyzowaæ naszego stanowiska wobec Joe Barr'a lepiej:
&quot;Ci±gle nie jest to najuczciwszy i najlepiej opracowany artyku³ 
na ¶wiecie, ale jest lepszy ni¿ kiedy¶.&quot; Mamy nadziejê, ¿e kiedy¶ przypadniemy 
sobie do gustu. Jednak uznanie za dojrza³o¶æ, mo¿emy tylko przypisaæ starzeniu siê 
i po czê¶ci zmêczeniu bezsensownymi k³ótniami.
</para>
</sect1>
</appendix>