Nářky vývojářů GCC 2.96 Pozadí: GCC řady 2.95 je oficiální GNU vydání a GCC verze 2.95.3 je nejméně chybovou verzí v sérii. Nikdy jsme nezaznamenali kompilační problémy, které bychom vystopovali až ke gcc-2.95.3. Počínaje Red Hat Linuxem 7.0, Red Hat zařadil silně patchovanou CVS verzi GCC do své distribuce a pojmenoval ji 2.96. Red Hat tuto verzi zařadil do distribuce, protože GCC 3.0 v té době nebylo dokončeno a potřebovali kompilátor, který by dobře fungoval na všech jimi podporovaných platformách, včetně IA64 a s390. Linuxový distributor Mandrake (nyní Mandriva) rovněž následoval příkladu Red Hatu a začal zařazovat GCC 2.96 do jejich řady Linux-Mandrake 8.0. Bilance: GCC tým odmítl jakoukoli spojitost s GCC 2.96 a vydal officiální vyjádření ke GCC 2.96. Mnoho vývojářů na světě začalo mít problémy s GCC 2.96 a několik projektů, mezi nimi i avifile, začalo doporučovat jiné kompilátory. Další zajímavé odkazy jsou Linux kernel news flash about kernel 2.4.17 a Voy Forum. Rovněž MPlayer trpěl občasnými problémy, které byly všechny vyřešeny přechodem na jinou verzi GCC. Několik projektů začalo implementovat "obchvaty" některých sporných míst 2.96, ale my jsme odmítli opravovat chyby jiných lidí, zvlášť když některé obchvaty mohou způsobit snížení výkonu. GCC 2.96 neumožňuje znaky | (roura) v assemblerových komentářích, jelikož podporuje jak syntaxi Intel, tak AT&T a znak | je ve variantě Intel symbolem. Problém je, že tiše ignoruje celý blok assembleru. To je snad již opraveno, GCC vypíše varování místo přeskočení bloku. Současnost: Red Hat říká, že GCC 2.96-85 a výš je opravený. Situace se mezi tím zlepšila. Stále vidíme problémy v našich konferencích, které zmizí s jiným kompilátorem. V mnoha případech na tom vůbec nezáleží. Doufáme, že dospívající GCC 3.x odstraní tyto problémy nadobro. Pokud chcete kompilovat s 2.96 zadejte volbu do configure. Pamatujte však, že jste v tom sami, nehlaste tedy žádné chyby. Pokud to uděláte, budete vyločeni z naší konference, jelikož již máme dost dohadování se (flame vars) ohledně GCC 2.96. Nechte to již prosíme být. Pokud máte problémy s GCC 2.96, můžete si opatřit balíčky 2.96-85 z ftp servru Red Hatu, nebo použít balíčky 3.0.4 nabízené od verze 7.2 a pozdějších. Rovněž si můžete opatřit balíčky gcc-3.2.3-37 (neofficiální, ale dobře fungující) a můžete je nainstalovat paralelně ke gcc-2.96, kterou již máte. MPlayer to zdetekuje a použije 3.2 místo 2.96. Pokud nechcete, nebo nemůžete použít binární balíčky, takto můžete zkompilovat GCC 3 ze zdrojových kódů: Běžte na stránku zrcadel GCC a stáhněte si gcc-core-XXX.tar.gz, kde XXX je číslo verze. Archiv obsahuje úplný kompilátor C a pro MPlayer je dostatečný. Pokud chcete i C++, Javu nebo některou jinou pokročilou vlastnost GCC, gcc-XXX.tar.gz vám bude vyhovovat lépe. Rozbalte archiv příkazem tar -xvzf gcc-core-XXX.tar.gz GCC není sestavováno do adresáře se zdrojovými kódy jako většina jiných programů, ale vyžaduje adresář mimo adresáře s kódy. Proto musíte tento adresář vytvořit pomocí mkdir gcc-build Pak můžete přistoupit ke konfiguraci gcc v sestavovacím adresáři, ale potřebujete configure ze zdrojového adresáře: cd gcc-build ../gcc-3.XXX/configure Zkompilujte GCC spuštěním tohoto příkazu v sestavovacím adresáři: make bootstrap Nyní můžete nainstalovat GCC (jako root) zadáním make install Binární distribuce MPlayer dříve obsahoval zdrojový kód z projektu OpenDivX, který znemožňoval binární distribuci. Tento kód byl od verze 0.90-pre1 odstraněn a zbývající soubor divx_vbr.c, který je odvozen ze zdrojových kódů OpenDivX byl svými autory vydán pod licencí GPL okolo verze 0.90pre9. Nyní si můžete vytvořit binární balíčky podle své chuti. Další překážkou v binární redistribuci byly optimalizace pro CPU architekturu při kompilaci. MPlayer nyní podporuje detekci CPU za běhu (zadejte volbu do configure). Tato vlastnost je ve výchozím nastavení vypnuta, jelikož způsobuje malé snížení rychlosti, ale umožňuje vytvářet binárky, které poběží na různých zástupcích Intel kompatibilních procesorů. nVidia Nelíbí se nám, že nVidia poskytuje pouze binární ovladače (pro použití s XFree86), které jsou často chybné. Máme mnoho hlášení o problémech s těmito ovladači v mplayer-users a jejich malé kvalitě, nestabilitě a slabé uživatelské a expertní podpoře. Mnoho z těchto problémů/chyb se neustále opakují. Později jsme byli kontaktováni nVidií a řekli nám, že tyto chyby neexistují, nestabilita je způsobena špatnými AGP čipy a oni nemají žádná hlášení o chybách ovladačů (jako je fialová čára). Takže pokud máte problémy se svou nVidia kartou, doporučujeme aktualizovat ovladač a/nebo si koupit nový motherboard, nebo požádat nVidii o dodání open-source ovladačů. V každém případě, pokud používáte binární ovladače od nVidie a máte problémy ve vztahu k ovladači, počítejte prosím s tím, že se vám dostane z naší strany jen malé pomoci, jelikož v tomto případě máme omezené možnosti. Joe Barr Joe Barr se stal neblaze proslulým v prosinci 2001 napsáním tvrdé(?) recenze MPlayeru nazvané MPlayer: Project z pekla. Shledal MPlayer těžko instalovatelným a usoudil, že vývojáři byli nepřátelští a dokumentace neúplná a urážlivá. Posuďte však sami. Negativně se zmínil o Arpim v článku 10 Linux predictions for 2002. V následující recenzi xine nazvané A streaming media player for the rest of us pak pokračoval v kontroverzní polemice. Ironií je, že na konci tohoto článku citoval svou výměnu názorů s Günterem Bartschem, původním autorem xine, která perfektně shrnuje celou situaci:
Ačkoli mi rovněž řekl, že byl "překvapen" mým sloupkem o Mplayeru a myslí si, že je nefér, připomenul mi, že je to svobodný softwarový projekt. "Když se vám nelíbí," řekl Bartsch, "můžete jej svobodně nepoužívat."
Téměř o dva roky později v říjnu 2003 napsal další recenzi nazvanou Mplayer revisited (chyby v gramatice vyhrazeny). Ve ketré uvedl následující závěry:
Je třeba říct, že jsou zde vylepšení v počtu vlastností, ve výkonu a v dokumentaci. Stále to není nejlehčí instalace na světě, zvláště pro nováčky, ale je to lepší, než to bylo.
a
Ale mnohem důležitější je, že jsem si zde nepovšiml žádných aktuálních komentářů o urážení uživatelů. Myslím, že je to i moje zásluha, dokonce i když to říkám sám o sobě. Arpi a zbytek vývojářů to museli cítit také tak, jelikož si dali práci, aby mě zmínili ve zvláštní sekci dokumentace obsažené v tarbalu. Jak jsem řekl na začátku, něktré věci se nezměnily.
Naše pocity k Joe Barrovi nemůžeme shrnout lépe než: "Stále to není nejférovější nebo nejfundovanější článek na světě, ale je lepší než předtím." Doufáme, že příště si vzájemně splníme svá očekávání. Zásluhu za naši vyspělost má výhradně náš vyšší věk a možná únava z flame wars.