mpv/DOCS/xml/hu/users-vs-dev.xml

<?xml version="1.0" encoding="iso-8859-2"?>
<!-- synced with r15895 -->
<appendix id="users-vs-dev">
<title>Fejleszt<EFBFBD>i panaszok</title>

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

<formalpara>
<title>A h<>tt<74>r:</title>
<para>
A GCC <emphasis role="bold">2.95</emphasis>-<2D>s sorozata egy hivatalos GNU kiad<61>s
<EFBFBD>s a GCC 2.95.3-as verzi<7A>ja a leghibamentesebb ebben a sorozatban. SOha nem
tapasztaltunk ford<72>t<EFBFBD>si probl<62>m<EFBFBD>kat, amik a gcc-2.95.3-ra lettek volna visszavezethet<65>ek.
A Red Hat Linux 7.0-t<>l kezd<7A>d<EFBFBD>en a <emphasis role="bold">Red Hat</emphasis> a
GCC egy er<65>sen patchelt CVS verzi<7A>j<EFBFBD>t tette bele a disztrib<69>ci<63>j<EFBFBD>ba, <20>s
<EFBFBD>tnevezte <emphasis role="bold">2.96</emphasis>-ra. A Red Hat az<61>rt vette bele
ezt a verzi<7A>t a disztrib<69>ci<63>j<EFBFBD>ba, mert a GCC 3.0 m<>g nem volt k<>sz abban az id<69>ben
<EFBFBD>s sz<73>ks<6B>g<EFBFBD>k volt egy ford<72>t<EFBFBD>ra, ami j<>l m<>k<EFBFBD>dik a t<>mogatott platformjaikon,
bele<EFBFBD>rtve az IA64-et <20>s az s390-et. A <emphasis role="bold">Mandrake</emphasis>
(most m<>r Mandriva) k<>vette a Red Hat p<>ld<6C>j<EFBFBD>t <20>s elkezdte sz<73>ll<6C>tani a GCC 2.96-ot
a saj<61>t Linux-Mandrake 8.0 sorozat<61>val.
</para>
</formalpara>

<formalpara>
<title>A helyzet:</title>
<para>
A GCC csapat visszautas<61>tott b<>rmif<69>le kapcsolatot a GCC 2.96-tal <20>s
kiadott egy <ulink url="http://gcc.gnu.org/gcc-2.96.html">hivatalos v<>laszt</ulink>
a GCC 2.96-ra. Sok fejleszt<7A>nek probl<62>m<EFBFBD>i t<>madtak a GCC 2.96-tal <20>s
sz<EFBFBD>mos projekt, k<>zt<7A>k az
<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>,
elkezdett m<>s ford<72>t<EFBFBD>kat javasolni.
<EFBFBD>rdekes link m<>g a
<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
Linux kernel news flash a 2.4.17-es kernelr<6C>l</ulink>
<EFBFBD>s a
<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>.
Az <application>MPlayer</application> is szenvedett id<69>szakos probl<62>m<EFBFBD>kkal,
amik mind megold<6C>dtak egy m<>sik GCC verzi<7A>ra val<61> <20>t<EFBFBD>ll<6C>ssal. Sz<53>mos
projekt elkezdett "megker<65>l<EFBFBD>seket" implement<6E>lni a 2.96 n<>h<EFBFBD>ny hib<69>j<EFBFBD>ra, de
mi nem vagyunk hajland<6E>ak m<>sok hib<69>it jav<61>tgatni, k<>l<EFBFBD>n<EFBFBD>sen mivel a jav<61>t<EFBFBD>sok
jelent<EFBFBD>sen rontj<74>k a teljes<65>tm<74>nyt.
</para>
</formalpara>

<para>
A GCC 2.96 nem engedi meg a <literal>|</literal> (pipe) karaktereket az assembler
kommentekben, mert t<>mogatja mind az Intel, mind az AT&amp;T szintaxis<69>t <20>s a
<literal>|</literal> karakter egy szimb<6D>lum az Intel vari<72>nsban. A
probl<EFBFBD>ma az, hogy <emphasis>jelz<EFBFBD>s n<>lk<6C>l</emphasis> figyelmen k<>v<EFBFBD>l hagyja a
teljes assembler blokkot. Ezt <20>ll<6C>t<EFBFBD>lag m<>r jav<61>tott<74>k, a GCC figyelmeztet<65> <20>zenetet
<EFBFBD>r ki a blokk kihagy<67>sa helyett.
</para>

<formalpara>
<title>A jelen:</title>
<para>
A Red Hat azt mondja, hogy a GCC 2.96-85 <20>s ez ut<75>niak jav<61>tva lettek. Az <20>gy
k<EFBFBD>zben tov<6F>bb bonyol<6F>dott, m<>g mindig tal<61>lunk olyan hibajelent<6E>seket a levelez<65>si
list<EFBFBD>inkon, amik m<>s ford<72>t<EFBFBD>val elt<6C>nnek. Mindegy, a tov<6F>bbiakban ez m<>r nem
sz<EFBFBD>m<EFBFBD>t. Rem<65>lhet<65>leg a k<>sz<73>l<EFBFBD> GCC 3.x megoldja ezt az <20>gyet. Ha m<>gis
2.96-tal akarsz ford<72>tani, add meg a <option>--disable-gcc-checking</option>
kapcsol<EFBFBD>t a <filename>configure</filename>-nak. Eml<6D>kezz r<>, hogy ezesetben a
magad ura vagy <20>s <emphasis role="bold">ne jelents semmilyen hib<69>t</emphasis>.
Ha m<>gis ezt teszed, csak kitilt<6C>st kaphatsz a levelez<65>si list<73>r<EFBFBD>l, mert
m<EFBFBD>r a sokn<6B>l is t<>bb flame volt a GCC 2.96 miatt. Pihentess<73>k az <20>gyet.
</para>
</formalpara>

<para>
Ha probl<62>m<EFBFBD>id vannak a GCC 2.96-tal, let<65>ltheted a 2.96-85 csomagokat a
Red Hat <ulink url="ftp://updates.redhat.com">ftp szerver<65>r<EFBFBD>l</ulink> vagy
egyszer<EFBFBD>en haszn<7A>ld a 3.0.4 csomagokat, amik a 7.2 <20>s k<>s<EFBFBD>bbi kiad<61>sokban
tal<EFBFBD>lhat<EFBFBD>ak. Let<65>ltheted a <ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">gcc-3.2.3-37 csomagokat</ulink>
is (nem hivatalos, de j<>l m<>k<EFBFBD>d<EFBFBD>) <20>s telep<65>theted a m<>r megl<67>v<EFBFBD> gcc-2.96
mell<EFBFBD>. Az <application>MPlayer</application> meg fogja tal<61>lni <20>s ink<6E>bb a
3.2-eset haszn<7A>lja a 2.96 helyett. Ha nem akarod vagy nem tudod haszn<7A>lni a
bin<EFBFBD>ris csomagokat, itt van, hogy tudod leford<72>tani forr<72>sb<73>l a GCC 3-at:
</para>

<procedure>
<step><para>
  Menj a
  <ulink url="http://gcc.gnu.org/mirrors.html">GCC t<>kr<6B>ket tartalmaz<61></ulink>
  oldal<61>ra <20>s t<>ltsd le a <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>
  f<>jlt, ahol <replaceable>XXX</replaceable> a verzi<7A> sz<73>m. Ebben benne van a
  teljes C ford<72>t<EFBFBD> <20>s elegend<6E> az <application>MPlayer</application>hez. Ha
  C++, Java vagy valamelyik m<>sik GCC funkci<63> is kell neked, a
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> jobban megfelel
  az ig<69>nyeidnek.
  </para></step>
<step><para>
  Csomagold ki az arch<63>vot a
  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
  paranccsal!
  </para></step>
<step><para>
  A GCC nem a forr<72>s k<>nyvt<76>rba ker<65>l leford<72>t<EFBFBD>sra, mint a legt<67>bb program,
  hanem kell neki egy kimeneti k<>nyvt<76>r valahol a forr<72>son k<>v<EFBFBD>l. <20>gy l<>tre
  kell hoznod egy k<>nyvt<76>rat a
  <screen>mkdir gcc-build</screen>
  paranccsal.
  </para></step>
<step><para>
  Ezut<75>n elv<6C>gezheted a gcc konfigur<75>l<EFBFBD>s<EFBFBD>t a c<>lk<6C>nyvt<76>rb<72>l, azonban a
  configure a forr<72>s k<>nyvt<76>rban van:
  <screen>
cd gcc-build
../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
  </para></step>
<step><para>
  Ford<72>tsd le a GCC-t a k<>vetkez<65> parancs kiad<61>s<EFBFBD>val a c<>lk<6C>nyvt<76>rban:
  <screen>make bootstrap</screen>
  </para></step>
<step><para>
  Most m<>r telep<65>theted a GCC-t (mint root) a
  <screen>make install</screen>
  parancs beg<65>pel<65>s<EFBFBD>vel.
  </para></step>
</procedure>
</sect1>


<sect1 id="mplayer-binary">
<title>Bin<EFBFBD>ris disztrib<69>ci<63>k</title>

<para>
Az <application>MPlayer</application> r<>gebben tartalmazott forr<72>st az
OpenDivX projektb<74>l, ami tiltja a bin<69>ris tov<6F>bbad<61>s<EFBFBD>t. Ezt a k<>dot elt<6C>vol<6F>tottuk
a 0.90-pre1 verzi<7A>ban <20>s a visszamard<72> <filename>divx_vbr.c</filename> f<>jlt,
ami az OpenDivX forr<72>s<EFBFBD>b<EFBFBD>l sz<73>rmazik, GPL terjeszt<7A>s al<61> vett<74>k a fejleszt<7A>i a
0.90pre9-es verzi<7A>ra. <20>gy m<>r nyugodtan k<>sz<73>thetsz bin<69>ris csomagokat, ha
<EFBFBD>gy tartja kedved.
</para>

<para>
A bin<69>ris tov<6F>bbterjeszt<7A>s m<>sik akad<61>lya a ford<72>t<EFBFBD>si id<69>ben t<>rt<72>n<EFBFBD> CPU
architekt<EFBFBD>r<EFBFBD>nak megfelel<65> optimaliz<69>ci<63> volt. Az <application>MPlayer</application>
most m<>r t<>mogatja a fut<75>sidej<65> CPU keres<65>st (add meg az
<option>--enable-runtime-cpudetection</option> kapcsol<6F>t a <command>configure</command>
parancsnak).
Alap<EFBFBD>rtelmez<EFBFBD>sk<EFBFBD>nt ki van kapcsolva, mert mag<61>ban hordoz egy kicsi
sebess<EFBFBD>gcs<EFBFBD>kken<EFBFBD>st, de <20>gy most m<>r lehets<74>ges olyan bin<69>risok l<>trehoz<6F>sa,
amelyek futnak az Intel kompatibilis CPU csal<61>d k<>l<EFBFBD>nb<6E>z<EFBFBD> tagjain.
</para>
</sect1>


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

<para>
Nem igaz<61>n <20>r<EFBFBD>l<EFBFBD>nk annak a t<>nynek, hogy az
<ulink url="http://www.nvidia.com">nVidia</ulink> csak bin<69>ris vez<65>rl<72>t
biztos<EFBFBD>t (az XFree86-tal t<>rt<72>n<EFBFBD> haszn<7A>lathoz), ami gyakran hib<69>s.
Rengeteg jelent<6E>st kaptunk az
<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
list<EFBFBD>n olyan probl<62>m<EFBFBD>kr<6B>l, amik ezekhez a z<>rt forr<72>sk<73>d<EFBFBD> vez<65>rl<72>kh<6B>z
kapcsl<EFBFBD>dtak <20>s ezek gyenge min<69>s<EFBFBD>g<EFBFBD>hez, instabilit<69>s<EFBFBD>hoz <20>s a felhaszn<7A>l<EFBFBD>i
tapasztalatlans<EFBFBD>ghoz.
Sok ilyen probl<62>ma/dolog ism<73>telten felt<6C>nik.
Nem r<>gen t<>rgyaltunk az nVidia-val <20>s azt mondt<64>k, hogy ezek a hib<69>k
nem l<>teznek, az instabilit<69>st a rossz AGP chip-ek okozz<7A>k <20>s hogy <20>k nem
kaptak jelent<6E>st vez<65>rl<72> hib<69>kr<6B>l (mint a r<>zsasz<73>n vonal). <20>gy ha probl<62>m<EFBFBD>d
van az nVidia k<>rty<74>ddal, azt tan<61>csoljuk, hogy friss<73>tsd az nVidia vez<65>rl<72>d
<EFBFBD>s/vagy vegy<67>l egy <20>j alaplapot vagy k<>rd meg az nVidia-t, hogy biztos<6F>tson
ny<EFBFBD>lt-forr<72>sk<73>d<EFBFBD> vez<65>rl<72>ket. B<>rmelyik esetben, ha az nVidia bin<69>ris vez<65>rl<72>j<EFBFBD>t
haszn<EFBFBD>lod <20>s vez<65>rl<72> probl<62>m<EFBFBD>id vannak, k<>rlek eml<6D>kezz r<>, hogy t<>l<EFBFBD>nk
nagyon kev<65>s seg<65>ts<74>get kaphatsz, mert nincs el<65>g energi<67>nk, hogy az ilyen
<EFBFBD>gyekben is seg<65>ts<74>nk.
</para>
</sect1>


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

<para>
Joe Barr 2001. december<65>ben lett el<65>g n<>pszer<65>tlen, amikor egy cs<63>ppet sem
kedves <application>MPlayer</application> <20>ttekint<6E>st k<>sz<73>tett,
<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: Projekt a pokolb<6C>l</ulink>
c<EFBFBD>mmel.
<EFBFBD>gy tal<61>lta, hogy az <application>MPlayer</application>t neh<65>z telep<65>teni <20>s
azt a k<>vetkeztet<65>st vonta le, hogy a fejleszt<7A>k bar<61>ts<74>gtalanok <20>s a
dokument<EFBFBD>ci<EFBFBD> nem teljes valamint s<>rt<72>. L<>gy te a b<>r<EFBFBD>!
Tov<EFBFBD>bb menve negat<61>van tett eml<6D>t<EFBFBD>st <20>rpir<69>l a
<ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>
c<EFBFBD>m<EFBFBD> cikkj<6B>ben.
Egy k<>vetkez<65> <20>ttekint<6E>sben, melyben a xine-r<>l <20>r
<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink>
c<EFBFBD>mmel, folytatja a bajkever<65>st. Ir<49>nikus m<>don ezen cikk v<>g<EFBFBD>n id<69>zi
G<EFBFBD>nter Bartsch-sal, a <application>xine</application> eredeti szerz<72>j<EFBFBD>vel
t<EFBFBD>rt<EFBFBD>nt eszmecser<65>j<EFBFBD>t, ami t<>k<EFBFBD>letesen <20>sszefoglalja az eg<65>sz szitu<74>ci<63>t:

<blockquote><para>
Azonban kihangs<67>lyozta, hogy &quot;meglep<EFBFBD>d<EFBFBD>tt&quot; az <application>Mplayer</application>r<EFBFBD>l
sz<EFBFBD>l<EFBFBD> <20>r<EFBFBD>somon <20>s <20>gy gondolta, hogy az nem fair, eml<6D>keztetve engem arra,
hogy az is egy szabad szoftver projekt. &quot;Ha nem szereted,&quot;
mondja Bartsch, &quot;szabad nem haszn<7A>lnod.&quot;
</para></blockquote>

Majdnem k<>t <20>vvel k<>s<EFBFBD>bb, 2003. okt<6B>ber<65>ben <20>rt egy m<>sik <20>ttekint<6E>st
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink>
c<EFBFBD>mmel (a hib<69>s <20>r<EFBFBD>sm<73>dot megtartottam).
Ebben az al<61>bbi k<>vetkeztet<65>sre jutott:

<blockquote><para>
Azt mondan<61>m, hogy van fejl<6A>d<EFBFBD>s a jellemz<6D>k sz<73>m<EFBFBD>t tekintve, teljes<65>tm<74>nyben,
<EFBFBD>s a dokument<6E>ci<63>ban. M<>g mindig nem a vil<69>g legk<67>nnyebb telep<65>t<EFBFBD>se, k<>l<EFBFBD>n<EFBFBD>sen
az <20>joncoknak, de kicsit jobb, mint r<>gen.
</para></blockquote>

<EFBFBD>s

<blockquote><para>
De ami m<>g fontosabb, nem tal<61>ltam semmilyen <20>j, felhaszn<7A>l<EFBFBD>kat s<>rt<72>
megjegyz<EFBFBD>st. <20>gy gondolom, ebben van egy kis r<>szem, m<>g akkor is, ha
csak <20>n gondolom <20>gy. <20>rpinak <20>s a projekt t<>bbi tagj<67>nak is <20>gy gondolhatja,
mert <20>gyeltek r<>, hogy megeml<6D>kezzenek r<>lam a dokument<6E>ci<63> egy speci<63>lis
r<EFBFBD>sz<EFBFBD>ben, ami a tarball-ban is megtal<61>lhat<61>. Mint ahogy az elej<65>n is
mondtam, n<>h<EFBFBD>ny dolog semmit sem v<>ltozott.
</para></blockquote>

Nem tudn<64>nk enn<6E>l jobban <20>sszefoglalni a Joe Barr ir<69>nti <20>rz<72>seinket:
&quot;Nem a legkorrektebb vagy legjobb ut<75>naj<61>r<EFBFBD>s alapj<70>n meg<65>rt cikk a
vil<EFBFBD>gon, de jobb, mint azel<65>tt volt.&quot; Tal<61>n a legk<67>zelebbi alkalommal
m<EFBFBD>r meg fogunk felelni egym<79>s elv<6C>r<EFBFBD>sainak. B<>r a be<62>r<EFBFBD>s<EFBFBD>rt j<>r<EFBFBD> k<>sz<73>net
csak az egyre m<>l<EFBFBD> id<69>t illeti meg <20>s tal<61>n az elf<6C>rad<61>st a flame h<>bor<6F>kban.
</para>

</sect1>
</appendix>