RepoMirrors/mpv
1
0
Fork 0
mirror of https://github.com/mpv-player/mpv synced 2025-03-25 04:38:01 +00:00
Code Issues Releases Wiki Activity

"At least next new file translated and very little fixes in the second."

Browse Source 
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@4815 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
gabucino 2002-02-22 23:41:55 +00:00
parent ac6944129f
commit 3687495972
2 changed files with 185 additions and 121 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
DOCS/Polish/bugreports.html
View File

@ -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 @@ domowej.</P>
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 @@ przyk
<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 @@ przyk
<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 @@ prze
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 @@ przez ftp oraz do
<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>

264
DOCS/Polish/users_against_developers.html
View File

@ -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>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><I>GCC 2.96 series</I></B></P>
<A NAME=gcc><P><B><I>serie GCC 2.96</I></B></P>
<P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></P>
<P><B>Przeczytaj też <A HREF="gcc-2.96-3.0.html">ten</A> tekst !!!</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><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>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>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>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><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>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>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>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>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><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>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>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><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>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>