changeset 4814:23abc0e262e3

"At least next new file translated and very little fixes in the second."
author gabucino
date Fri, 22 Feb 2002 23:41:55 +0000
parents 15e95b9cf191
children 178b524e5213
files DOCS/Polish/bugreports.html DOCS/Polish/users_against_developers.html
diffstat 2 files changed, 185 insertions(+), 121 deletions(-) [+]
line wrap: on
line diff
--- a/DOCS/Polish/bugreports.html	Fri Feb 22 19:52:09 2002 +0000
+++ b/DOCS/Polish/bugreports.html	Fri Feb 22 23:41:55 2002 +0000
@@ -6,7 +6,7 @@
 
 <P><B><A NAME=C>Dodatek C - Jak zgłaszać błędy</A></B></P>
 
-<P><B>Jak zgłaszać błędy ?</B></P>
+<P><B>Jak zgłaszać błędy?</B></P>
 
 <P> Najpierw sprawdź ostatnie CVS, być może twój błąd został już poprawiony.
 Instrukcje (nieskomplikowane), jak ściągnąć CVS, znajdziesz na naszej stronie
@@ -16,25 +16,25 @@
 D</A> i inne dokumenty. Jeżeli twój problem nie jest znany lub nie rozwiązują
 go nasze instrukcje, wtedy zgłoś błąd: </P>
 
-<P><B>Gdzie ?</B></P>
+<P><B>Gdzie?</B></P>
 
 <P>Zapisz się na listę użytkowników mplayera:<BR>
 &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://mplayerhq.hu/mailman/listinfo/mplayer-users">http://mplayerhq.hu/mailman/listinfo/mplayer-users</A><BR>
 i wyślij swój raport do:<BR>
 &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="mailto:mplayer-users@mplayehq.hu">mplayer-users@mplayerhq.hu</A><BR>
-Nie odpiszemy bezpośrednio więc pamiętaj, aby zasubskrybować listę!!!</P>
+Nie odpiszemy bezpośrednio, więc pamiętaj, aby zasubskrybować listę!!!</P>
 
 <P> Nie wysyłaj raportów o błędach prywatnie, bezpośrednio na adres autora!!!
 Pracujemy wspólnie nad kodem, więc wszyscy są zainteresowani.  Swoją drogą,
 często inni użytkownicy znają rozwiązanie (problemy z konfiguracją systemu, złe
-sterowniki itd.), nawet kiedy my myślimy, że to błąd w kodzie.  Językiem tej
-listy jest ANGIELSKI!  </P>
+sterowniki itd.), nawet kiedy my myślimy, że to błąd w kodzie. Językiem tej
+listy jest ANGIELSKI!</P>
 
 <P>Opisz swój problem ze szczegółami i nie zapomnij dołączyć tego:</P>
 
-<P><B>Czego ?</B></P>
+<P><B>Czego?</B></P>
 
-<P><B><I>1.Informacja o systemie, jaką chcemy znać:</I></B></P>
+<P><B><I>1.Informacja o systemie, jaką zawsze chcemy dostać:</I></B></P>
 
 <UL>
 <LI>dystrybucja linuksa<BR>
@@ -47,7 +47,7 @@
     <CODE>ls -l /lib/libc[.-]*</CODE>
 <LI>wersja X:<BR>
     <CODE>X -version</CODE>
-<LI>wersje gcc i ld:<BR>
+<LI>wersja gcc i ld:<BR>
     <CODE>gcc -v<BR>
     ld -v</CODE>
 <LI>wersja binutils:<BR>
@@ -59,13 +59,13 @@
 <UL>
 <LI>informacja o CPU:<BR>
     <CODE>cat /proc/cpuinfo</CODE>
-<LI>producent i model karty video:<BR>
+<LI>producent i model karty wideo:<BR>
     przykłady:<BR><UL>
     <LI>ASUS V3800U chip: nVidia TNT2 Ultra pro 32MB SDRAM
     <LI>Matrox G400 DH 32MB SGRAM</UL>
 <LI>typ i wersja sterownika karty graficznej<BR>
     przykłady:<UL>
-    <LI>sterownik dostarczony w X
+    <LI>wbudowany sterownik X-ów
     <LI>nvidia 0.9.623
     <LI>Utah-GLX CVS 2001-02-17
     <LI>DRI z X 4.0.3</UL>
@@ -105,14 +105,13 @@
   Załaduj to przez ftp, a na listę wyślij tylko ścieżkę/nazwę pliku. Jeżeli
   plik jest dostępny przez sieć, to wystarczy wysłać _dokładny_ URL do niego.
 
-<P><B><I>5. :W przypadku przerwań w działaniu programu ( segfault, SIGILL, sygnał 4 itd.):</I></B></P>
+<P><B><I>5. W przypadku przerwań w działaniu programu ( segfault, SIGILL, sygnał 4 itd.):</I></B></P>
 
-<P><I>Jeżeli masz coredump po tym zdarzeniu, patrz 5.a, jeśli nie patrz 5.b:</I></P>
+<P><I>Jeżeli masz coredump po tym zdarzeniu, zobacz 5.a, jeśli nie - zobacz 5.b:</I></P>
 
 <P><B><I>5.a: Zapisz i wyślij nam coredump (jeżeli został stworzony).</I></B></P>
 
-<P>Jak to zrobić:
-Utwórz następujący skrypt:</P>
+<P>Jak to zrobić: utwórz następujący skrypt:</P>
 
 <P><CODE>disass $eip-32 $eip+32<BR>
 printf "eax=%08lX\n",$eax<BR>
@@ -151,20 +150,19 @@
 <P><B>Wiem co robię...</B></P>
 
 <P> Jeśli stworzyłeś właściwy raport o błędzie, postępując zgodnie z podanymi
-wskazówkami oraz jesteś pewien, że to błąd mplayera, nie kompilatora czy
+wskazówkami oraz jesteś pewien, że to błąd mplayera, nie kompilatora, czy
 zepsutego pliku, przeczytałeś dokumentację i nadal nie znalazłeś rozwiązania,
-a twoje sterowniki kart dźwiękowej są w porządku, wówczas możesz zasubskrybować
+a twoje sterowniki karty dźwiękowej są w porządku, wówczas możesz zasubskrybować
 listę dyskusyjną mplayer-advusers i wysłać swój raport, aby dostać szybszą i
 lepszą odpowiedź.
-Ale strzeż się: jeśli wyślesz pytanie w stylu początkującego użytkownika bądź w
-typie rtfm, natychmiast zostaniesz zbanowany, nawet nie uzyskując często
-odpowiedzi na swoje pytania.   
+Ale STRZEŻ SIĘ: jeśli wyślesz pytanie w stylu początkującego użytkownika, bądź
+w typie rtfm ("read the fucken manual" - przeczytaj pieprzony manual),
+natychmiast zostaniesz zbanowany, zazwyczaj nie uzyskując nawet odpowiedzi na
+swoje pytania.   
 A więc nie drażnij nas, zasubskrybuj -advusers tylko, jeśli naprawdę wiesz, co
 robisz i czujesz, że jesteś już zaawansowanym użytkownikiem lub developerem
 mplayera (a propos tego, jak subskrybować: dowiedz się sam! jeśli jesteś
 naprawdę zaawansowanym użytkownikiem, nie powinno to być dla ciebie problemem
-...).
-</P>
-
+...).</P>
 </BODY>
 </HTML>
--- a/DOCS/Polish/users_against_developers.html	Fri Feb 22 19:52:09 2002 +0000
+++ b/DOCS/Polish/users_against_developers.html	Fri Feb 22 23:41:55 2002 +0000
@@ -5,117 +5,183 @@
 
 <P><B><I>In medias res</I></B></P>
 
-<P>There are two major topic which always causes huge dispute and flame on the
-<A HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">mplayer-users</A>
-mailing list. Number one is of course the topic of the</P>
-
-<P><B><I>GCC 2.96 series</I></B></P>
+<P>Są takie dwa tematy, które zawsze wywołują wielką dyskusję i ogniste boje na
+liście dyskusyjnej <A
+HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">użytkowników mplayera</A>.
+Tematem numer jeden jest:</P>
 
-<P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></P>
+<A NAME=gcc><P><B><I>serie GCC 2.96</I></B></P>
 
-<P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
-best of them was 2.95.3 . Please note the style of the version numbering.
-This is how the GCC team numbers their compilers. The 2.95 series are good.
-We never ever saw anything that was miscompiled because of the 2.95's faultiness.</P>
+<P><B>Przeczytaj też <A HREF="gcc-2.96-3.0.html">ten</A> tekst !!!</B></P>
 
-<P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
-with their distributions. Note the version numbering. This should be the GCC
-team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
-They patched it very deep, and used this version in the distrib because 3.0
-wasn't out at time, and they wanted IA64 support ASAP (business reasons).
-Oh, and GCC 2.95 miscompiles bash on the s390 architecture (there is
-no RedHat distribution for s390..) .</P>
+<P><I>Tło</I>: były/są serie GCC <B>2.95</B>. 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.</P>
 
-<P>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the
-<CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version of
-2.96 (apparently it needs this option on <B>egcs</B> too. It's because we don't
-test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>).
-If you know <B>MPlayer</B>, you should know that it has great speed. It
-achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and
-lots of other features. <B>MPlayer</B> contained MMX/3DNow instructions in a
-syntax that all Linux compilers accept it... except RedHat's GCC (it's more
-standard compliant). It simply <B><I>skips</I></B> them. It doesn't give
-errors. It doesn't give warnings. <B>And</B>, there is Lame. With gcc 2.96, its quality check
-(<CODE>make test</CODE> after compiling) <I>doesn't even run !!!</I>
-But hey, it compiles bash on s390 and IA64.</P>
-
-<P>The <I>statements</I> : most developers around the world begun having
-bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
-compile with other compiler than 2.96 . RedHat users' disappointment slowly
-went into anger. What was all good
-for, apart from giving headaches to developers, putting oil on anti-RedHat
-flame, confusing users? The answer, I do not know.</P>
+<P><I>Poczynania</I>: <B>RedHat</B> rozpoczął włączanie wersji GCC <B>2.96</B>
+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..).</P>
 
-<P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
-is fixed, and works properly. Note the versioning. They should have started
-with something like this. What about GCC 2.96.85 ? It doesn't matter now.
-I don't search, but I still see bugs with 2.96 . It doesn't matter now,
-hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
-Towards a deep patched 3.0...
-</P>
+<P><I>Fakty</I>: proces kompilacji <B>MPlayera</B> wymaga
+<CODE>--disable-gcc-checking</CODE>, aby pominąć wykrywanie wersji GCC 2.96
+(wyraźnie wymagana jest ta opcja przy <B>egcs</B> również; to dlatego, że my
+nie testujemy <B>MPlayera</B> na egcs. Proszę nam wybaczyć, ale my raczej
+zajmujemy się rozwijaniem <B>MPlayera</B>). Jeżeli znasz <B>MPlayera</B>,
+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. <B>MPlayer</B> 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
+<B><I>przeskakuje</I></B>. Nie zgłasza błędów. Nie wysyła ostrzeżeń. <B>I</B>,
+tam jest "Lame". Z gcc 2.96, sprawdzanie jakości (<CODE>make test</CODE> po
+kompilacji) <I>nawet się nie uruchamia!!!</I> Hej, ale on kompiluje bash na
+s390 i IA64.</P>
 
-<P><I>What I don't understand</I> is why are we hated by RedHat users for
-putting warning messages, and stay-away documents in <B>MPlayer</B> .
-Why are we called "brain damaged", "total asshole", "childish" by
-<B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .
-They even considered forking <B>MPlayer</B> for themselves. RedHat users.
-Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us?
-Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold
-a grudge against users, doesn't matter how loud you advertise its contrary.
-Please go flame Linus Torvalds, the DRI developers (oh, now I know why
-there were laid off by VA!), the Wine, avifile. Even if we are arrogant,
-are we not the same as the previously listed ones? Why do <B>we</B> have
-to suffer from your unrightful wrath?</P>
+<P><I>Wnioski</I>: 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.</P>
 
-<P>I'm closing this topic. Think over it please. I (Gabucino) personally begun
-with <A HREF="http://www.redhat.com">RedHat</A>, then used Mandrake (sorry I
-don't know their URL), now I have <A
-HREF="http://www.linuxfromscratch.com">LFS</A>. Never held a grudge against
-RedHat or RedHat users, and I still don't. Hate is only comfortable. It
-won't bring you anywhere.</P>
-
-<P><B><I>Binary distribution of MPlayer</I></B></P>
-
-<P>Tons of users asked us about this. For example Debian users tend to say: Oh,
-I can <CODE>apt-get install avifile</CODE>, why should I <B>compile MPlayer</B> ?
-While this may sound reasonable, the problem lies a bit deeper than
-those-fuckin-MPlayer-developers-hate-gcc-2.96-and-RedHat-and-Debian.</P>
-
-<P>Reasons: <B>Law</B></P>
+<P><I>Teraźniejszość</I>: 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
+<B>RedHat zapomni o 2.96</B> i skieruje się ku <B>3.0</B>. W kierunku
+porządnie załatanego 3.0...</P>
 
-<P><B>MPlayer</B> describes the <U>sourcecode</U>. It contains several files with incompatible
-licenses especially on the redistribution clauses. As source files, they are
-allowed to coexist in a same project.</P>
-
-<P>Therefore, <U>NEITHER BINARIES NOR BINARY PACKAGES OF <B>MPlayer</B> ARE ALLOWED TO EXIST SINCE
-SUCH OBJECTS BREAK LICENSES</U>. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE
-DOING ILLEGAL ACTIVITIES.</P>
+<P><I>To, czego ja tu nie rozumiem</I>, 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 <B>MPlayerze</B>. Dlaczego jesteśmy nazywani
+"umysłowo upośledzonymi", "totalnymi dupkami", "dziecinnymi w swoim myśleniu"
+przez <B>użytkowników RedHata</B>, na naszej mailowej liście dyskusyjnej, a
+nawet na liście <B>redhat-devel</B>. Rozważali oni nawet stworzenie odgałęzienia
+<B>MPlayera</B> dla nich samych. Użytkownicy RedHata. Dlaczego? Czy to RedHat
+stworzył kompilator, dlaczego <U>wy</U> musicie nas nienawidzieć? Jesteście aż
+<U>takimi</U> 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 <B>my</B> musimy cierpieć z powodu niesłusznego gniewu?</P>
 
-<P>So if you know somebody who maintains a binary package then forward her/him
-this text and (ask him to) contact us. What (s)he is doing is illegal and IT IS
-NO LONGER <B>MPlayer</B>, but <U>his/her</U> mplayer. If it breaks, it is
-his/her fault. Don't come and cry on the <B>MPlayer</B> mailing lists, you will
-most likely be blacklisted.</P>
-
-<P>Reasons: <B>Technical</B></P>
+<P><A HREF="mailto:willis_matthew@yahoo.com">Matt Willis</A> uprzejmie
+dostarczył proste howto (jak to zrobić) kompilacji GCC-3.0.3, które poniżej
+zamieszczam:</P>
 
 <P>
 <UL>
-  <LI><B>MPlayer's</B> speed (MMX, SSE, fastmemcpy, etc) optimizations are
-    determined during compilation. Thus a compiled binary contains very
-    processor-specific code. An <B>MPlayer</B> binary compiled for K6 will die
-    on Pentiums and vice versa. This has to be workarounded by runtime
-    detection, which is not an easy thing to do becase it causes massive speed
-    decrease. If you don't believe (it was explained in details 10000 times on
-    mplayer-users, search the archive), solve it and send us a patch. Someone
-    begun work on it, but disappeared since then.</LI>
-  <LI><B>MPlayer's</B> video/audio system is not plugin based. It is compiled
-    into the binary, thus making the binary depend on various libraries (the
-    GUI depends on GTK, DivX4 depends on libdivxdecore, SDL depends on libSDL,
-    every SDL release contains an unique bug that has to be workarounded during
-    compiletime, X11 output compiles differently for X3 and X4, etc). You may
-    say: yes, let's make 30 versions of downloadable binaries! We won't. We
-    will make these stuff pluggable in the future.</LI>
+ <LI>Ściągnij gcc. Idź na stronę: <A
+  HREF="http://gcc.gnu.org/mirrors.html">http://gcc.gnu.org/mirrors.html</A>.
+   Ja ściągnąłem następujące pliki, ale ty nie potrzebujesz ich wszystkich:<BR>
+    <CODE>gcc-g++-3.0.3.tar.gz<BR>
+    gcc-objc-3.0.3.tar.gz<BR>
+    gcc-3.0.3.tar.gz<BR>
+    gcc-g77-3.0.3.tar.gz<BR>
+    gcc-testsuite-3.0.3.tar.gz<BR>
+    gcc-core-3.0.3.tar.gz<BR>
+    gcc-java-3.0.3.tar.gz</CODE>
+  </LI>
+
+  <LI>Rozpakuj pliki, stwórz katalog w którym będizesz budował i zbuduj:
+  <CODE><PRE>
+     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</PRE></CODE>
+
+  <LI>Ustaw swoją ścieżkę, aby zawierała /opt/bin<BR>
+     <CODE>export PATH=/opt/bin:${PATH}</CODE>
+
+  <LI>Teraz możesz budować MPlayera.</LI>
+</UL>
+</P>
+
+<A NAME=binary><P><B><I>Dystrybucja MPlayera w postaci binariów</I></B></P>
+
+<P>Tony użytkowników proszą nas o to. Na przykład użytkownicy Debiana maja
+zwyczaj mówić: Oh, mogę zrobić <CODE>apt-get install avifile</CODE>, dlaczego
+mam <B>kompilować MPlayera</B>? To brzmi rozsądnie, ale problem leży nieco
+głębiej, niż:
+ci-pieprzeni-developerzy-MPlayera-nienawidzą-gcc-2.96-i-RedHata-i-Debiana.</P>
+
+<P>Przyczyny: <B>Prawo</B></P>
+
+<P><B>MPlayer</B> zapisany jest jako <U>źródła</U>. 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.</P>
+
+<P>Jednakże <U>ANI BINARIA, ANI BINARNE PAKIETY <B>MPlayera</B> NIE MAJĄ PRAWA
+ISTNIEĆ W CHWILI, GDY TAKIE OBIEKTY ŁAMIĄ LICENCJE</U>. LUDZIE, KTÓRZY
+ROZPROWADZAJĄ TAKIE PAKIETY BINARNE POSTĘPUJĄ NIELEGALNIE.</P>
+
+<P>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 <B>MPlayer</B>, a <U>jego/jej</U> mplayer.
+Jeśli źle działa, to to jest jego/jej wina. Niech nikt nie przychodzi i nie
+żali się na listę mailową <B>MPlayera</B>, bo najprawdopodobniej zostanie
+zapisany na czarną listę.</P>
+
+<P>Przyczyny: <B>Techniczne</B></P>
+
+<P>
+<UL>
+  <LI>Optymalizacja szybkości działania <B>MPlayera</B> (MMX, SSE, fastmemcpy,
+    itp) jest zdeterminowana podczas kompilacji. Z tego powodu skompilowane
+    binaria zawierają bardzo specyficzny dla danego procesora kod.  Binaria
+    <B>MPlayera</B> skompilowane dla K6 nie będą wydolne na procesorach Pentium
+    i vice versa. To zostało rozpracowane poprzez wykrywanie runtime, co nie
+    jest łatwą do obejścia zrobienia, gdyż sprawia masową utratę prędkości.
+    Jeśli nie wierzysz (to było juz 10000 razy wyjaśnione w szczegółach na
+    mplayer-users, przeszukaj archiwum), to rozwikłaj to i wyślij nam patch.
+    Ktoś zaczął nad tym pracować, ale nie ma o nim wieści od tamtej pory.</LI>
+  <LI>System audio/video <B>MPlayera</B> nie jest oparty na systemie
+    wtyczek. System audio/video jest wkompilowany w binaria, co powoduje
+    zależność binariów od różnych bibliotek (GUI zależy od GTK, DivX4 zależy od
+    libdivxdecore, SDL zależy od libSDL, każde wydanie SDL zawiera unikalny
+    błąd, ktory musi być ominięty w czasie kompilacji, X11 wyjście w różny
+    sposób się kompiluje X3 i X4, itp). Możesz powiedzieć: więc zróbmy 30
+    wersji binariów do ściągnięcia! Nie zrobimy tego. Zrobimy te rzeczy w
+    postaci wtyczek w przyszłości.</LI>
 </UL>
 
+<A NAME=nvidia><P><B><I>NVidia</I></B></P>
+
+<P>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ą.</P>
+
+<A NAME=kotsog><P><B><I>Joe Barr</I></B></P>
+
+<P>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?]).</P>
+
+<P>Oto kilka cytatów wypowiedzi różnych ludzi na temat Joe Barr (tylko po to,
+abyś zrozumiał, dlaczego on się kompletnie nie liczy):</P>
+
+<P><I>"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."</I></P>
+
+<P><I>"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.  "</I></P>
 </HTML>