In medias res
Są takie dwa tematy, które zawsze wywołują wielką dyskusję i ogniste boje na liście dyskusyjnej użytkowników mplayera. Tematem numer jeden jest:
serie GCC 2.96
Przeczytaj też ten tekst !!!
Tło: były/są serie GCC 2.95. Najlepszą z nich była 2.95.3. Zwróć uwagę na sposób numerowania wersji jądra. Oto jak drużyna GCC numeruje swoje kompilatory. Serie 2.95 są dobre. Nigdy nie widziano, aby coś źle się skompilowało z przyczyny błędów w 2.95.
Poczynania: RedHat rozpoczął włączanie wersji GCC 2.96 w swoich dystrybucjach. Zwróć uwagę na numerację wersji. To powinno być numerowanie drużyny GCC. Oni nałożyli łatę na wersję CVS GCC (coś na pograniczu 2.95 a 3.0). Ta łata była bardzo poważna i tej werji użyto do dystrybucji, ponieważ wersja 3.0 nie była skończona na czas, a oni chcieli mieć obsługę IA64 ASAP (z powodów własnych interesów). A przecież GCC 2.95 źle kompiluje bash na architekturze s390 (nie ma dystrybucji RedHata dla s390..).
Fakty: proces kompilacji MPlayera wymaga
--disable-gcc-checking
, aby pominąć wykrywanie wersji GCC 2.96
(wyraźnie wymagana jest ta opcja przy egcs również; to dlatego, że my
nie testujemy MPlayera na egcs. Proszę nam wybaczyć, ale my raczej
zajmujemy się rozwijaniem MPlayera). Jeżeli znasz MPlayera,
powinieneś wiedzieć, że jest on bardzo szybki. Osiąga to poprzez
zoptymalizowanie kodu dla MMX/SSE/3DNow/itp., dzięki fastmemcpy i wielu innym
właściwościom. MPlayer zawierał instrujkcje MMX/3DNow w składni, którą
wszystkie kompilatory Linuksowe akceptują ... za wyjątkiem GCC RedHata (to
określenie jest bardziej zgodne ze standardem). On po prostu je
przeskakuje. Nie zgłasza błędów. Nie wysyła ostrzeżeń. I,
tam jest "Lame". Z gcc 2.96, sprawdzanie jakości (make test
po
kompilacji) nawet się nie uruchamia!!! Hej, ale on kompiluje bash na
s390 i IA64.
Wnioski: większość developerów na świecie zaczęło mieć złe odczucia w związku z GCC 2.96 RedHata. Powiedzieli oni swoim użytkownikom RedHat'a, aby używali do kompilacji innych kompilatorów, niż 2.96. Rozczarowanie użytkowników RedHata powoli przemieniło się w gniew. Co było takiego dobrego, w przeciwieństwie do bólu głowy developerów, w dolewaniu oliwy do anty-RedHatowskiego ognia, wprawiającym użytkowników w konsternację? Ja nie znam odpowiedzi na to pytanie.
Teraźniejszość: RedHat twierdzi, że GCC 2.96-85 i kolejne wersje są naprawione i pracują właściwie. Zwróć uwagę na numerację wersji.To typowe, że zaczęli z czymś takim. A co z GCC 2.96.85? Nieistotne. Nie szukam, ale wciąż widzę błędy w 2.96. To jest bez znaczenia teraz, miejmy nadzieję, że RedHat zapomni o 2.96 i skieruje się ku 3.0. W kierunku porządnie załatanego 3.0...
To, czego ja tu nie rozumiem, to z jakiego powodu jesteśmy oblegani przez użytkowników RedHata, żalących się na komunikaty ostrzegawcze i dokumenty w rodzaju "trzymaj się z dala" w MPlayerze. Dlaczego jesteśmy nazywani "umysłowo upośledzonymi", "totalnymi dupkami", "dziecinnymi w swoim myśleniu" przez użytkowników RedHata, na naszej mailowej liście dyskusyjnej, a nawet na liście redhat-devel. Rozważali oni nawet stworzenie odgałęzienia MPlayera dla nich samych. Użytkownicy RedHata. Dlaczego? Czy to RedHat stworzył kompilator, dlaczego wy musicie nas nienawidzieć? Jesteście aż takimi wyznawcami RedHata? Proszę, przestańcie. My nie chowamy urazy do użytkowników, nie ważne jak głośno ogłaszacie coś przeciwnego. Idźcie, proszę, użerać się z Linusem Torvaldsem, z developerami DRI (och, teraz wiem już dlaczego oni zostali opuszczeni przez VA!), Wine, avifile. Jeśli nawet jesteśmy aroganccy, czy nie jesteśmy tacy sami jak wcześniej wspomniani? Dlaczego to my musimy cierpieć z powodu niesłusznego gniewu?
Matt Willis uprzejmie dostarczył proste howto (jak to zrobić) kompilacji GCC-3.0.3, które poniżej zamieszczam:
gcc-g++-3.0.3.tar.gz
gcc-objc-3.0.3.tar.gz
gcc-3.0.3.tar.gz
gcc-g77-3.0.3.tar.gz
gcc-testsuite-3.0.3.tar.gz
gcc-core-3.0.3.tar.gz
gcc-java-3.0.3.tar.gz
tar xvzf gcc-*3.0.3.tar.gz
mkdir gcc-build; cd gcc-build
../gcc-3.0.3/configure --prefix=/opt --program-suffix=-3.0.3
make bootstrap; mkdir -p /opt; make install
export PATH=/opt/bin:${PATH}
Dystrybucja MPlayera w postaci binariów
Tony użytkowników proszą nas o to. Na przykład użytkownicy Debiana maja
zwyczaj mówić: Oh, mogę zrobić apt-get install avifile
, dlaczego
mam kompilować MPlayera? To brzmi rozsądnie, ale problem leży nieco
głębiej, niż:
ci-pieprzeni-developerzy-MPlayera-nienawidzą-gcc-2.96-i-RedHata-i-Debiana.
Przyczyny: Prawo
MPlayer zapisany jest jako źródła. Zawiera on kilka plików z niekompatybilnymi liecencjami w punktach dotyczących redystrybucji. Jako źródłowe pliki, mają one prawo współistnieć w tym samym projekcie.
Jednakże ANI BINARIA, ANI BINARNE PAKIETY MPlayera NIE MAJĄ PRAWA ISTNIEĆ W CHWILI, GDY TAKIE OBIEKTY ŁAMIĄ LICENCJE. LUDZIE, KTÓRZY ROZPROWADZAJĄ TAKIE PAKIETY BINARNE POSTĘPUJĄ NIELEGALNIE.
Więc jeśli znasz kogoś, kto rozporządza binarnymi pakietami, wówczas daj mu do przeczytania ten tekst i (poproś go o) kontakt z nami. To co on/ona robi, jest nielegalne I TO JUŻ NIE JEST MPlayer, a jego/jej mplayer. Jeśli źle działa, to to jest jego/jej wina. Niech nikt nie przychodzi i nie żali się na listę mailową MPlayera, bo najprawdopodobniej zostanie zapisany na czarną listę.
Przyczyny: Techniczne
NVidia
Nie lubimy binarnych sterowników nvidii, ich jakości, niestabilności, nieistniejącego wsparcia dla użytkowników, wciąż pojawiających się nowych błędów. Większość użytkowników ma do nich podobne podejście. Skontaktowali się z nami później ludzie z NVidii i powiedzieli, że te błędy nie istnieją, niestabilność jest winą chipów AGP i odmówili opublikowania raportu o błędach sterownika (np. o fioletowej linii). Więc jeśli masz problem ze swoją NVidią, uaktualizuj sterownik nvidii i/lub kup nową płytę główną.
Joe Barr
On nie odpowiada na nasze maile. Jego wydawca nie odpowiada na nasze maile. Sieć jest pełna jego fałszywych stwierdzeń i oskarżeń (on widocznie nei lubi na przykład chłopaków z BSD, z powodu różnicy poglądów [na jaki temat?]).
Oto kilka cytatów wypowiedzi różnych ludzi na temat Joe Barr (tylko po to, abyś zrozumiał, dlaczego on się kompletnie nie liczy):
"Wszyscy pamiętacie LinuxWorld 2000, kiedy on twierdził, że Linus T. powiedział, że FreeBSD, to garstka developerów. Linus nie powiedział NICZEGO w tym rodzaju. Kiedy to wypomniano Joe'mu, jego reakcją było wyzwanie ludzi utrzymujących BSD of dupków i glupków."
"On jest interesujący, ale kiepsko mu wychodzi unikanie ... kontrowersyjności. Joe Barr był regularnym uczestnikiem forum Willa Zachmanna w Compuserve, kilka lat temu. Był zwolennikiem OS/2 (ja również byłem zwolennikiem OS/2). Często przekraczał wszelkie granice, rozwścieczając ludzi i podejrzewam, że to były ciężkie czasy dla niego. Trochę złagodniał ostatnio, będąc ocenionym przez własny dział redakcyjny. Stonowany, subtelny humor nie był jednak jesgo stylem w tamtych wczesnych dniach w zupełności. "