annotate DOCS/xml/hu/users-vs-dev.xml @ 15929:782c636d50c8

synced with 1.76

<?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>