path: root/DOCS/xml/hu/users-vs-dev.xml

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

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

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

<formalpara>
<title>A helyzet:</title>
<para>
A GCC csapat visszautasított bármiféle kapcsolatot a GCC 2.96-tal és
kiadott egy <ulink url="http://gcc.gnu.org/gcc-2.96.html">hivatalos választ</ulink>
a GCC 2.96-ra. Sok fejlesztõnek problémái támadtak a GCC 2.96-tal és
számos projekt, köztük az
<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>,
elkezdett más fordítókat javasolni.
É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õl</ulink>
és a
<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>.
Az <application>MPlayer</application> is szenvedett idõszakos problémákkal,
amik mind megoldódtak egy másik GCC verzióra való átállással. Számos
projekt elkezdett "megkerüléseket" implementálni a 2.96 néhány hibájára, de
mi nem vagyunk hajlandóak mások hibáit javítgatni, különösen mivel a javítások
jelentõsen rontják a teljesítmé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át és a
<literal>|</literal> karakter egy szimbólum az Intel variánsban. A
probléma az, hogy <emphasis>jelzés nélkül</emphasis> figyelmen kívül hagyja a
teljes assembler blokkot. Ezt állítólag már javították, a GCC figyelmeztetõ üzenetet
ír ki a blokk kihagyása helyett.
</para>

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

<para>
Ha problémáid vannak a GCC 2.96-tal, letöltheted a 2.96-85 csomagokat a
Red Hat <ulink url="ftp://updates.redhat.com">ftp szerverérõl</ulink> vagy
egyszerûen használd a 3.0.4 csomagokat, amik a 7.2 és késõbbi kiadásokban
találhatóak. Letö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ödõ) és telepítheted a már meglévõ gcc-2.96
mellé. Az <application>MPlayer</application> meg fogja találni és inkább a
3.2-eset használja a 2.96 helyett. Ha nem akarod vagy nem tudod használni a
bináris csomagokat, itt van, hogy tudod lefordítani forrásból a GCC 3-at:
</para>

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


<sect1 id="mplayer-binary">
<title>Bináris disztribúciók</title>

<para>
Az <application>MPlayer</application> régebben tartalmazott forrást az
OpenDivX projektbõl, ami tiltja a bináris továbbadását. Ezt a kódot eltávolítottuk
a 0.90-pre1 verzióban és a visszamardó <filename>divx_vbr.c</filename> fájlt,
ami az OpenDivX forrásából származik, GPL terjesztés alá vették a fejlesztõi a
0.90pre9-es verzióra. Így már nyugodtan készíthetsz bináris csomagokat, ha
úgy tartja kedved.
</para>

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


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

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


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

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

<blockquote><para>
Azonban kihangsúlyozta, hogy &quot;meglepõdött&quot; az <application>Mplayer</application>rõl
szóló írásomon és úgy gondolta, hogy az nem fair, emlékeztetve engem arra,
hogy az is egy szabad szoftver projekt. &quot;Ha nem szereted,&quot;
mondja Bartsch, &quot;szabad nem használnod.&quot;
</para></blockquote>

Majdnem két évvel késõbb, 2003. októberében írt egy másik áttekintést
<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink>
címmel (a hibás írásmódot megtartottam).
Ebben az alábbi következtetésre jutott:

<blockquote><para>
Azt mondanám, hogy van fejlõdés a jellemzõk számát tekintve, teljesítményben,
és a dokumentációban. Még mindig nem a világ legkönnyebb telepítése, különösen
az újoncoknak, de kicsit jobb, mint régen.
</para></blockquote>

és

<blockquote><para>
De ami még fontosabb, nem találtam semmilyen új, felhasználókat sértõ
megjegyzést. Úgy gondolom, ebben van egy kis részem, még akkor is, ha
csak én gondolom így. Árpinak és a projekt többi tagjának is így gondolhatja,
mert ügyeltek rá, hogy megemlékezzenek rólam a dokumentáció egy speciális
részében, ami a tarball-ban is megtalálható. Mint ahogy az elején is
mondtam, néhány dolog semmit sem változott.
</para></blockquote>

Nem tudnánk ennél jobban összefoglalni a Joe Barr iránti érzéseinket:
&quot;Nem a legkorrektebb vagy legjobb utánajárás alapján megírt cikk a
világon, de jobb, mint azelõtt volt.&quot; Talán a legközelebbi alkalommal
már meg fogunk felelni egymás elvárásainak. Bár a beérésért járó köszönet
csak az egyre múló idõt illeti meg és talán az elfáradást a flame háborúkban.
</para>

</sect1>
</appendix>