Mercurial > mplayer.hg
view DOCS/xml/hu/users-vs-dev.xml @ 15883:b656bb4945cc
synced with 1.15
author | gabrov |
---|---|
date | Sat, 02 Jul 2005 08:39:10 +0000 |
parents | f4d7886224cd |
children | 40c64f577133 |
line wrap: on
line source
<?xml version="1.0" encoding="iso-8859-1"?> <!-- synced with 1.16 --> <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> 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&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 "meglepődött" 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. "Ha nem szereted," mondja Bartsch, "szabad nem használnod." </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: "Nem a legkorrektebb vagy legjobb utánajárás alapján megírt cikk a világon, de jobb, mint azelőtt volt." 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>