Mercurial > mplayer.hg

changeset 4814:23abc0e262e3

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
"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>