diff --git a/DOCS/xml/hu/users-vs-dev.xml b/DOCS/xml/hu/users-vs-dev.xml new file mode 100644 index 0000000000..1a810c1e66 --- /dev/null +++ b/DOCS/xml/hu/users-vs-dev.xml @@ -0,0 +1,234 @@ + + + +Fejlesztői panaszok + + +GCC 2.96 + + +A háttér: + +A GCC 2.95-ö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 Red Hat a +GCC egy erősen patchelt CVS verzióját tette bele a disztribúciójába, és +átnevezte 2.96-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 Mandrake 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. + + + + +A helyzet: + +A GCC csapat visszautasított bármiféle kapcsolatot a GCC 2.96-tal és +kiadott egy hivatalos választ +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 +avifile, +elkezdett más fordítókat javasolni. +Érdekes link még a + +Linux kernel news flash a 2.4.17-es kernelről +és a +Voy Forum. +Az MPlayer 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. + + + + +A GCC 2.96 nem engedi meg a | (pipe) karaktereket az assembler +kommentekben, mert támogatja mind az Intel, mind az AT&T szintaxisát és a +| karakter egy szimbólum az Intel variánsban. A +probléma az, hogy jelzés nélkül 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. + + + +A jelen: + +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 +kapcsolót a configure-nak. Emlékezz rá, hogy ezesetben a +magad ura vagy és ne jelents semmilyen hibát. +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. + + + + +Ha problémáid vannak a GCC 2.96-tal, letöltheted a 2.96-85 csomagokat a +Red Hat ftp szerveréről 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 gcc-3.2.3-37 csomagokat +is (nem hivatalos, de jól működő) és telepítheted a már meglévő gcc-2.96 +mellé. Az MPlayer 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: + + + + + Menj a + GCC tükröket tartalmazó + oldalára és töltsd le a gcc-core-XXX.tar.gz + fájlt, ahol XXX a verzió szám. Ebben benne van a + teljes C fordító és elegendő az MPlayerhez. Ha + C++, Java vagy valamelyik másik GCC funkció is kell neked, a + gcc-XXX.tar.gz jobban megfelel + az igényeidnek. + + + Csomagold ki az archívot a + tar -xvzf gcc-core-XXX.tar.gz + paranccsal! + + + 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 + mkdir gcc-build + paranccsal. + + + 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: + +cd gcc-build +../gcc-3.XXX/configure + + + Fordítsd le a GCC-t a következő parancs kiadásával a célkönyvtárban: + make bootstrap + + + Most már telepítheted a GCC-t (mint root) a + make install + parancs begépelésével. + + + + + + +Bináris disztribúciók + + +Az MPlayer 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ó divx_vbr.c 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. + + + +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 MPlayer +most már támogatja a futásidejű CPU keresést (add meg az + kapcsolót a configure +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. + + + + + +nVidia + + +Nem igazán örülünk annak a ténynek, hogy az +nVidia 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 +mplayer-users +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. + + + + + +Joe Barr + + +Joe Barr 2001. decemberében lett elég népszerűtlen, amikor egy csöppet sem +kedves MPlayer áttekintést készített, +MPlayer: Projekt a pokolból +címmel. +Úgy találta, hogy az MPlayert 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 +10 Linux predictions for 2002 +című cikkjében. +Egy következő áttekintésben, melyben a xine-ról ír +A streaming media player for the rest of us +címmel, folytatja a bajkeverést. Irónikus módon ezen cikk végén idézi +Günter Bartsch-sal, a xine eredeti szerzőjével +történt eszmecseréjét, ami tökéletesen összefoglalja az egész szituációt: + +
+Azonban kihangsúlyozta, hogy "meglepődött" az Mplayerrő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." +
+ +Majdnem két évvel később, 2003. októberében írt egy másik áttekintést +Mplayer revisited +címmel (a hibás írásmódot megtartottam). +Ebben az alábbi következtetésre jutott: + +
+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. +
+ +és + +
+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. +
+ +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. + + + +