🚀 go-pugleaf

i co dziwne zalezy od obciazenia procesora
0% -> 15kB/s
100% -> 30Mb/s

ktos ma pomysl jak zwalony if_rl naprawic ?

W dniu 2010-05-14 18:34, arturbac pisze:
> i co dziwne zalezy od obciazenia procesora
> 0% -> 15kB/s
> 100% -> 30Mb/s
> 
> ktos ma pomysl jak zwalony if_rl naprawic ?

PS: uzywam nowiutki D-Link DFE-528TX i testowalem takze na drugiej
karcie Planet takze rl

arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
> i co dziwne zalezy od obciazenia procesora
> 0% -> 15kB/s
> 100% -> 30Mb/s
> ktos ma pomysl jak zwalony if_rl naprawic ?

raczej zwalony modem - źle się dogaduje. próbuj ręcznie ustawiać half lub
full duplex

W dniu 2010-05-14 20:05, Wojciech Puchar pisze:
> arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
>> i co dziwne zalezy od obciazenia procesora
>> 0% -> 15kB/s
>> 100% -> 30Mb/s
>> ktos ma pomysl jak zwalony if_rl naprawic ?
> 
> raczej zwalony modem - źle się dogaduje. próbuj ręcznie ustawiać half lub
> full duplex

pytanie dlaczego 2wa modem'y (cisco, motorolla) dzialaja z innymi
kartami ok up/down

z realteakmi (2ma) dlink i planet up jest ok 2.4Gb, a down tylko ok gdy
na bsd procek ma pelne obciazenie ?
czy to pelne obciazenie moze miec jaki kolwiek zwiazek z modemem ?
Bo mi to raczej wyglada na nie generowanie przerwan przez karty-driver
if_rl i zastanawiam sie czy nie sprobowac z polling(4) ?

rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>
        inet .............
        ether 00:26:5a:e5:bf:a3
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

> 
> pytanie dlaczego 2wa modem'y (cisco, motorolla) dzialaja z innymi
> kartami ok up/down

Bo niestety zarówno modemy jak i karty często nie spełniają standardów jeśli
chodzi o autonegocjacje. Zwykle współgrają czasem nie.

Osobiście z cisco miałem zawsze problemy. 

> Bo mi to raczej wyglada na nie generowanie przerwan przez karty-driver
> if_rl i zastanawiam sie czy nie sprobowac z polling(4) ?

nic to nie zmieni. 
 
> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        options=8<VLAN_MTU>
>        inet .............
>        ether 00:26:5a:e5:bf:a3
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active

spróbuj 

a) ifconfig rl0 media 100baseTX mediaopt half-duplex 

(wątpie czy coś da)

b) pożycz taniego switcha i podłącz go pomiędzy karte a ten modem.

A i B powinno rozjaśnić ci sytuacje.

W dniu 2010-05-14 20:17, Wojciech Puchar pisze:
> a) ifconfig rl0 media 100baseTX mediaopt half-duplex 

ifconfig rl0 media 100baseTX
wylacza full, ale nic nie dalo.

> b) pożycz taniego switcha i podłącz go pomiędzy karte a ten modem.
> 
> A i B powinno rozjaśnić ci sytuacje.

niestety nie mam, bede musial kupic jakas inna karte, em dzialaja dobrze
na freebsd a do tego czasu napisalem "program" ;-)
int main() { for(;;);}

yy> 
> ifconfig rl0 media 100baseTX
> wylacza full, ale nic nie dalo.
> 
>> b) pożycz taniego switcha i podłącz go pomiędzy karte a ten modem.
>> 
>> A i B powinno rozjaśnić ci sytuacje.
> 
> niestety nie mam, bede musial kupic jakas inna karte, em dzialaja dobrze
> na freebsd

nie ma na to reguły. zależy co jest po drugiej stronie.

ja akurat gdzieś np. mam tylko realteka bo nic innego nie działało.
realtek też tylko po ustawieniu ręcznie trybu po OBU stronach.
ty nie masz takiej opcji.

Zamiast kupować spróbuj z pożyczonymi switchami.

> a do tego czasu napisalem "program" ;-)
> int main() { for(;;);}

cat /dev/zero >/dev/null robi to samo bez kompilacji ;)

arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
> i co dziwne zalezy od obciazenia procesora
> 0% -> 15kB/s
> 100% -> 30Mb/s
> 
> ktos ma pomysl jak zwalony if_rl naprawic ?

Zmienić kartę. Te realteki tak mają - to co normalnie wykonuje
chip na karcie, w realtekach robi procesor (dzięki temu są tanie).

Weź sobie jakiegoś Intela na przykład (fxp) czy innego 3Coma (xl).

Ponc
-- 
Kto misiowi urwał ucho?

W dniu 2010-05-15 15:10, Tomasz Piłat pisze:
> Zmienić kartę. Te realteki tak mają - to co normalnie wykonuje
> chip na karcie, w realtekach robi procesor (dzięki temu są tanie).
> 
> Weź sobie jakiegoś Intela na przykład (fxp) czy innego 3Coma (xl).

najgorsze ze kupilem d-linka a to sie okazalo to samo gowno na rl co
poprzednio planet.

>> 100% -> 30Mb/s
>> 
>> ktos ma pomysl jak zwalony if_rl naprawic ?
> 
> Zmienić kartę. Te realteki tak mają - to co normalnie wykonuje
> chip na karcie, w realtekach robi procesor (dzięki temu są tanie).

to nie o to chodzi. gdybyś miał racje to ZAWSZE by źle działały. i tym
gorzej im bardziej zajęty procesor.

On 15.05.2010, arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
> W dniu 2010-05-15 15:10, Tomasz Piłat pisze:
>> Zmienić kartę. Te realteki tak mają - to co normalnie wykonuje
>> chip na karcie, w realtekach robi procesor (dzięki temu są tanie).
>> 
>> Weź sobie jakiegoś Intela na przykład (fxp) czy innego 3Coma (xl).
>
> najgorsze ze kupilem d-linka a to sie okazalo to samo gowno na rl co
> poprzednio planet.

Wniosek, że nie należy kupować w ciemno sprzętu.

-- 
Dominik Zyla

Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
>>> 100% -> 30Mb/s
>>> 
>>> ktos ma pomysl jak zwalony if_rl naprawic ?
>> 
>> Zmienić kartę. Te realteki tak mają - to co normalnie wykonuje
>> chip na karcie, w realtekach robi procesor (dzięki temu są tanie).
> 
> to nie o to chodzi. gdybyś miał racje to ZAWSZE by źle działały. i tym
> gorzej im bardziej zajęty procesor.

Dokładnie o to chodzi. Te 100% zajętości generuje właśnie karta.

Ponc
-- 
Kto misiowi urwał ucho?

>> 
>> to nie o to chodzi. gdybyś miał racje to ZAWSZE by źle działały. i tym
>> gorzej im bardziej zajęty procesor.
> 
> Dokładnie o to chodzi. Te 100% zajętości generuje właśnie karta.

to przeczytaj jeszcze raz wcześniejsze maile i to co napisał pytający....

W dniu 2010-05-16 17:19, Wojciech Puchar pisze:
>>>
>>> to nie o to chodzi. gdybyś miał racje to ZAWSZE by źle działały. i tym
>>> gorzej im bardziej zajęty procesor.
>>
>> Dokładnie o to chodzi. Te 100% zajętości generuje właśnie karta.
> 
> to przeczytaj jeszcze raz wcześniejsze maile i to co napisał pytający....
> 
pisałem dokładnie co innego:
rl bez obciązenia proceosra nie działa download tj działa na poziomie
20kB/s!
z 100% obciązeniem proceosra (jakakolwiek apliakcja) działa normalnie
download.
upload zawsze działa okbez wzgledu na cpu

>>>
>>> Dokładnie o to chodzi. Te 100% zajętości generuje właśnie karta.
>> 
>> to przeczytaj jeszcze raz wcześniejsze maile i to co napisał pytający....
>> 
> pisałem dokładnie co innego:
> rl bez obciązenia proceosra nie działa download tj działa na poziomie
> 20kB/s!
> z 100% obciązeniem proceosra (jakakolwiek apliakcja) działa normalnie
> download.

czyli nie karta generuje obciążenie ale gdy jest obciążenie - karta działa
"lepiej". a ściślej - jest większe opóźnienie wysłania pakietu zwrotnego i
może dzięki temu coś jest lepiej.

albo problem z negocjacją albo z PCI

W dniu 2010-05-17 14:47, Wojciech Puchar pisze:
> czyli nie karta generuje obciążenie ale gdy jest obciążenie - karta działa
> "lepiej". a ściślej - jest większe opóźnienie wysłania pakietu zwrotnego i
> może dzięki temu coś jest lepiej.

bardzo dziwne, bo jeśli to prowda to jak kupie jakąs em'ke problem
pozostałby tyle że em'ka w tym kompie działa ok obsługując lan.
> 
> albo problem z negocjacją albo z PCI

Jeśli problem z PCI to czemu starszej karcie ed nie robiło to problemu i
chodziła na granicy swojej możliwości 1MB/s ?
Sprawdzałem już trzy gniazda i tylko rl ma problem , em i ed nie.

> bardzo dziwne, bo jeśli to prowda to jak kupie jakąs em'ke problem
> pozostałby tyle że em'ka w tym kompie działa ok obsługując lan.
>> 
>> albo problem z negocjacją albo z PCI
> 
> Jeśli problem z PCI to czemu starszej karcie ed nie robiło to problemu i
> chodziła na granicy swojej możliwości 1MB/s ?
> Sprawdzałem już trzy gniazda i tylko rl ma problem , em i ed nie.

więc na 100% problem z autonegocjacją - tak jak pisałem na początku. 
dobrze że zmiana karty na em pomogła.

nie wyciągaj tylko wniosku że karty z chipsetem realtek są do d.
nie są. RTL8139 są tanie i dobre i zajmują NIECO więcej CPU przy odbiorze,
wyraźnie więcej przy wysyłce ale nawet przy sprzęcie <1GHz różnicy nie czuć.
A przy używaniu tam gdzie nie będzie 100Mbit/s tylko mniej - to tym bardziej
są dobre.

Ja miałem odwrotną sytuację - z switchem zarządzalnym cisco operatora do
którego podłączałem serwer NIE działała karta intela (em), ani broadcom
(bge). Najtańszy realtek działa za to idealnie.

On Mon, 17 May 2010 17:26:04 +0000 (UTC), Wojciech Puchar
<wojtek@wojtek.tensor.gdynia.pl> wrote:

> nie są. RTL8139 są tanie i dobre i zajmują NIECO więcej CPU przy odbiorze,
> wyraźnie więcej przy wysyłce ale nawet przy sprzęcie <1GHz różnicy nie czuć.
> A przy używaniu tam gdzie nie będzie 100Mbit/s tylko mniej - to tym bardziej
> są dobre.

 Są mniej więcej tak samo zajebiste, jak pamięci bez korekcji
 (nie wspominając już o pamięciach uszkodzonych). Nie ma dla nich
 miejsca w serwerach.

 r.
-- 
_________________________________________________________________
robert rędziak     e36/5 323ti     mailto:giekao-at-gmail-dot-com

   I hope they don't fart at Greenpeace. That's bad for Gaia.

>> A przy używaniu tam gdzie nie będzie 100Mbit/s tylko mniej - to tym bardziej
>> są dobre.
> 
> Są mniej więcej tak samo zajebiste, jak pamięci bez korekcji
> (nie wspominając już o pamięciach uszkodzonych). Nie ma dla nich
> miejsca w serwerach.
> 
Jak zwykle - twoje słowo było niezwykle cenne.

W dniu 2010-05-17 19:26, Wojciech Puchar pisze:

> nie wyciągaj tylko wniosku że karty z chipsetem realtek są do d.
> nie są.

Zgadza sie takie idiotyczne problemy 1) są tylko we FreeBSD 2) i zaczęło
sie to dziać od 5.x po odejściu paru dobrych programistów do Dragona.

1) na własnej skórze już przeciwczyłem np kaszane na dyskach SATA 2 i
mcp55 oczywiscie tylko freebsd ma ten problem, windows i linux nie mial.

2) Jakosc sterownikow nie jest dla mnie wyznacznikiem jakosci systemu bo
FBSD uwielbiam w roli serwera i mam go od lat (6.x a wczesniej 4.x) ale
niesamowicie mnie irytuje ze tak pieprza je w wersjach produkcyjnych os.
Przez co moj serwer chodzi ciagle na 6.x i starej plycie z athlonem mimo
iz obok mam wolny spzret kilak razy szybszy i z kilkanascie razy wieksza
iloscia ram.

>> nie wyciągaj tylko wniosku że karty z chipsetem realtek są do d.
>> nie są.
> 
> Zgadza sie takie idiotyczne problemy 1) są tylko we FreeBSD 2) i zaczęło
> sie to dziać od 5.x po odejściu paru dobrych programistów do Dragona.

Z tym też się nie zgadzam. DragonflyBSD miał być cudo, jest do d.

Możliwe że FreeBSD 6 miało jakiś problem z realtek (nie przypominam sobie)
sprawdzałeś 7.3?


> 
> 1) na własnej skórze już przeciwczyłem np kaszane na dyskach SATA 2 i
> mcp55 oczywiscie tylko freebsd ma ten problem, windows i linux nie mial.

nie wiem co to jest mcp55, ja z dyskami SATA pod FreeBSD nie miałem
problemów.
co do linux - owszem.

> 
> 2) Jakosc sterownikow nie jest dla mnie wyznacznikiem jakosci systemu bo

Jakość sterowników w FreeBSD średnio patrząc jest znakomita.

> FBSD uwielbiam w roli serwera i mam go od lat (6.x a wczesniej 4.x) ale
> niesamowicie mnie irytuje ze tak pieprza je w wersjach produkcyjnych os.
> Przez co moj serwer chodzi ciagle na 6.x i starej plycie z athlonem mimo

7.3 możesz śmiało używać! 8-ki nie.

W dniu 2010-05-18 09:13, Wojciech Puchar pisze:
> Z tym też się nie zgadzam. DragonflyBSD miał być cudo, jest do d.

dfly nie biore pod uwage bo to prawie martwy projekt.

> 
> Możliwe że FreeBSD 6 miało jakiś problem z realtek (nie przypominam sobie)
> sprawdzałeś 7.3?
> 7.3 możesz śmiało używać! 8-ki nie.

Jescze nie zwariowalem, 6.3 a teraz 6.4 dziala mi bardzo stabilnie od
lat i nie widze sensu ruszac wszystkiego z uwagi na sterownik karty
tylko po to by sprowadzic nowe problemy  z innymi elementami systemu
ktore ulegly zmianie.

W dniu 2010-05-18 00:11, arturbac pisze:
> 1) na własnej skórze już przeciwczyłem np kaszane na dyskach SATA 2 i
> mcp55 oczywiscie tylko freebsd ma ten problem, windows i linux nie mial.

PS: to ćwiczylem na 7.0 i 7.1 z tego co pamietam.

W dniu 2010-05-18 15:46, arturbac pisze:
> 
> W dniu 2010-05-18 00:11, arturbac pisze:
>> 1) na własnej skórze już przeciwczyłem np kaszane na dyskach SATA 2 i
>> mcp55 oczywiscie tylko freebsd ma ten problem, windows i linux nie mial.
> 
> PS: to ćwiczylem na 7.0 i 7.1 z tego co pamietam.

i dodam że równolegle na tym samym kompie 6.3 x86,x64 nie miało problemów.
Odradzam 7.x i 8.x komukolwiek do czegokolwiek poza testowaniem kodu.

On Mon, 17 May 2010 19:03:05 +0000 (UTC), Wojciech Puchar
<wojtek@wojtek.tensor.gdynia.pl> wrote:

>> Są mniej więcej tak samo zajebiste, jak pamięci bez korekcji
>> (nie wspominając już o pamięciach uszkodzonych). Nie ma dla nich
>> miejsca w serwerach.
>> 
> Jak zwykle - twoje słowo było niezwykle cenne.

 Moje słowo jest takie, że puszczamy Fribsdę na PE1955 oraz
 PE2x50 (od 2650 do 2950 III włącznie) i nie mamy z nią żadnych
 problemów, chociaż do sprawy podchodzimy konserwatywnie i na
 produkcji używamy wciąż 6.x. Co więcej, jak nam się zaczęły
 pamięci sypać (ogólnie jakość serwerów Della od jakiegoś czasu
 leci na pysk, ale to inna sprawa), to fribsda posłusznie
 zaliczyła glebę, podczas gdy pingwin radośnie zaczął
 przekłamywać pliki na fs-ach.

 A Ty, jak chcesz, to nadal używaj gównianego sprzętu i drutuj
 go, uważając że to jest właściwa droga.

 r (pokarmię jeszcze, szkoda żeby usechł ;)).
-- 
_________________________________________________________________
robert rędziak     e36/5 323ti     mailto:giekao-at-gmail-dot-com

   I hope they don't fart at Greenpeace. That's bad for Gaia.

>> 
>> PS: to ćwiczylem na 7.0 i 7.1 z tego co pamietam.
> 
> i dodam że równolegle na tym samym kompie 6.3 x86,x64 nie miało problemów.
> Odradzam 7.x i 8.x komukolwiek do czegokolwiek poza testowaniem kodu.

Sprawdź 7.3
Używam go na wszystkich PRODUKCYJNYCH komputerach (inna sprawa że innych
komputerów z FreeBSD nie posiadam)

w 7.1 były błędy.

W 8.* jest W CH... błędów narazie.

Co mi się nie podoba to prędkość wprowadzania nowych wersji jako
produkcyjnych w FreeBSD. 

W dniu 2010-05-18 18:22, Wojciech Puchar pisze:
> Co mi się nie podoba to prędkość wprowadzania nowych wersji jako
> produkcyjnych w FreeBSD. 

Otóż to, do 4.x było inaczej.

>> Co mi się nie podoba to prędkość wprowadzania nowych wersji jako
>> produkcyjnych w FreeBSD. 
> 
> Otóż to, do 4.x było inaczej.

Niestety nie ma zbyt wyboru NARAZIE.

Linux - szkoda gadać.
NetBSD - było to dobre do czasu "sponsoringu" przez jakąś firme
(wasabisystems czy jakoś tak). Ani wasabisystems ani NetBSD na tym najlepiej
nie wyszło, w szczególności to drugie - błędów od groma, żółwi się i
funkcjonalnie raczej słabo jak na dziś.
Tyle że obsługuje bardzo wiele platform. W moim przypadku przydatność tego
mała.

OpenBSD - dużo gadania o "bezpieczeństwie" które nie jest ani troche większe
niż w innych BSD, w końcu to zależy od tego jakie programy się uruchamia.
Błędów w kernelu skutkujących dziurami w żadnym BSD praktycznie nie ma, jak
są to jest święto.

Poza tym - wydajność koszmarna.

DragonflyBSD - no czekam dalej, jak narazie ten system, który miałbyć
"FreeBSD zrobionym poprawnie" - działa znacznie wolniej od FreeBSD w
warunkach realnej pracy. HammerFS brzmi ciekawie i w sensie pomysłu znacznie
lepszy od ZFS. W sensie praktycznym czekamy... 

Więc co zostało. W razie jeśli nowe wersje FreeBSD będą robione już w stylu
"nowoczesnym" czyli byle jak najszybciej zawsze można będzie robić backporty
sterowników.

Zresztą - zapotrzebowanie na porządny system unix istnieje. Jest znacznie
mniejsze niż na zabaweczki do klikania ale znaczące. A Wolny Rynek nie znosi
próżni.

Jeśli FreeBSD się popsuje pojawi się alternatywa. Może darmowa a może
płatna.

Jak dla mnie - gdybym miał w tej chwili płacić za to co oferuje FreeBSD i
nie byłaby to cena z kosmosu, i jednocześnie byłaby normalna obsługa klienta
jak w komercyjnym produkcie (tzn. jest błąd = wiadomo gdzie zgłosić = jest
reakcja i naprawa), to nie widze problemu.

On 18.05.2010, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:

> OpenBSD - dużo gadania o "bezpieczeństwie" które nie jest ani troche większe
> niż w innych BSD, w końcu to zależy od tego jakie programy się uruchamia.
> Błędów w kernelu skutkujących dziurami w żadnym BSD praktycznie nie ma, jak
> są to jest święto.
>
> Poza tym - wydajność koszmarna.

Do zastosowań sieciowych jest całkiem fajne. PF we FreeBSD jest dość
leciwy.

> Więc co zostało. W razie jeśli nowe wersje FreeBSD będą robione już w stylu
> "nowoczesnym" czyli byle jak najszybciej zawsze można będzie robić backporty
> sterowników.

Jeśłi ma sprostać potrzebom rynku, tak właśnie powinno być rozwijane. I
bardzo dobrze, że tak właśnie to się dzieje.

-- 
Dominik Zyla

>> OpenBSD - dużo gadania o "bezpieczeństwie" które nie jest ani troche większe
>> niż w innych BSD, w końcu to zależy od tego jakie programy się uruchamia.
>> Błędów w kernelu skutkujących dziurami w żadnym BSD praktycznie nie ma, jak
>> są to jest święto.
>>
>> Poza tym - wydajność koszmarna.
> 
> Do zastosowań sieciowych jest całkiem fajne. PF we FreeBSD jest dość
> leciwy.

Całkiem możliwe. Tyle że ja wole IPFW z FreeBSD od KAŻDEJ wersji PF. 

Ale znaleźliśmy JAKIEŚ zastosowanie do OpenBSD ;)

> 
>> Więc co zostało. W razie jeśli nowe wersje FreeBSD będą robione już w stylu
>> "nowoczesnym" czyli byle jak najszybciej zawsze można będzie robić backporty
>> sterowników.
> 
> Jeśłi ma sprostać potrzebom rynku, tak właśnie powinno być rozwijane. I

Rynek na tym polega że ma wielu klientów i wiele nisz rynkowych. Więc nie
istnieje jedna potrzeba rynku.

> bardzo dobrze, że tak właśnie to się dzieje.
Co to jest "potrzeba rynku" w przypadku oprogramowania które jest za darmo?

W dniu 2010-05-18 23:02, Dominik Zyla pisze:
> Jeśłi ma sprostać potrzebom rynku, tak właśnie powinno być rozwijane. I
> bardzo dobrze, że tak właśnie to się dzieje.

dobrze że rozwija się, ale w 4.x stable BYŁO stable a nie alpha.
FreeBSD zzaczyna przypominac mi inny porojekt Mono.
Mają już najnowsze ficzery z 3.5 i chyba 4.0 .NET ale stan implementacji
2.0 i windows forms to ser szwajcarski, skutek taki że Mono po latach
nadal nie nadaje sie do niczego powżnego i nie ma portów aplikacji z
.NET z windy.

IMHO nie tędy droga.

On 18.05.2010, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
>> bardzo dobrze, że tak właśnie to się dzieje.
> Co to jest "potrzeba rynku" w przypadku oprogramowania które jest za darmo?

To, że ów oprogramowanie jest w stanie sprostać potrzebom firm, firm,
których zysk często zależy właśnie od sprawności jego działania. 

Myślę, że sam powinieneś wiedzieć doskonale, orędowniku darmowego
oprogramowania w postaci FreeBSD i blaszaków z uszkodzoną pamięcią. :)

-- 
Dominik Zyla

>> Co to jest "potrzeba rynku" w przypadku oprogramowania które jest za darmo?
> 
> To, że ów oprogramowanie jest w stanie sprostać potrzebom firm, firm,
> których zysk często zależy właśnie od sprawności jego działania. 

Gdyby tak było to właśnie nikt nie parłby w te wszystkie nowe głupoty.

> Myślę, że sam powinieneś wiedzieć doskonale, orędowniku darmowego
> oprogramowania w postaci FreeBSD i blaszaków z uszkodzoną pamięcią. :)

Jak nie umiesz rozumieć tego co pisze to się palancie po prostu nie odzywaj.

Albo w sumie co mi tam gadaj sobie będzie Ci lżej i poczujesz się lepszym.

> 
> dobrze że rozwija się, ale w 4.x stable BYŁO stable a nie alpha.

No niestety. 

> FreeBSD zzaczyna przypominac mi inny porojekt Mono.

Złe porównanie.

> Mają już najnowsze ficzery z 3.5 i chyba 4.0 .NET ale stan implementacji
> 2.0 i windows forms to ser szwajcarski, skutek taki że Mono po latach
> nadal nie nadaje sie do niczego powżnego i nie ma portów aplikacji z
> .NET z windy.

Akurat to słuszne, bo tak samo jak .net i windows - ma się nadawać do
niczego ;) i lepiej nie będzie.

Chcesz wdrażać winrozwiązania to stosuj windows. proste.

On 19.05.2010, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
> Jak nie umiesz rozumieć tego co pisze to się palancie po prostu nie odzywaj.

hehe, i tym właśnie zdaniem pokazałeś swój poziom.

-- 
Dominik Zyla

On 2010-05-19 11:32, Dominik Zyla wrote:
> On 19.05.2010, Wojciech Puchar<wojtek@wojtek.tensor.gdynia.pl>  wrote:
>> Jak nie umiesz rozumieć tego co pisze to się palancie po prostu nie odzywaj.
>
> hehe, i tym właśnie zdaniem pokazałeś swój poziom.

Nie kłóćmy się :(

W dniu 2010-05-19 10:12, Wojciech Puchar pisze:
> Chcesz wdrażać winrozwiązania to stosuj windows. proste.

nie jest proste.

Mam apliakcje rozproszona , konsolową (MPI) i wolalbym czesc procesow
robczych odpalac na maszynach z freebsd (koszty) zamiast na winserver
ale to nie mozliwe bo mono nie dosc ze dziurawe to nie ma implementacji
obslugujacej kod hybrydowy c++/c++cli

>>> Jak nie umiesz rozumieć tego co pisze to się palancie po prostu nie odzywaj.
>>
>> hehe, i tym właśnie zdaniem pokazałeś swój poziom.
> 
> Nie kłóćmy się :(

Nikt się nie kłóci. Niektórzy tylko nie znoszą takich jak ja co mają inne
zdanie niż "powszechnie przyjęte" i strasznie zdołowani wyrywkowo czytają
moje wypowiedzi żeby "pokazać mi".

A swoim ostatnim popisem człowiek wykazał to co napisałem - że jest zwykłym
palantem.

Bo jak inaczej nazwać mój opis testowanie czegoś na uszkodzonym sprzęcie -
uznany przez niego że ja powszechnie i świadomie używam uszkodzonego sprzętu
do normalnej pracy.

> nie jest proste.
> 
> Mam apliakcje rozproszona , konsolową (MPI) i wolalbym czesc procesow
> robczych odpalac na maszynach z freebsd (koszty) zamiast na winserver
> ale to nie mozliwe bo mono nie dosc ze dziurawe to nie ma implementacji
> obslugujacej kod hybrydowy c++/c++cli

To co piszesz pozornie jest logiczne. Ale tylko pozornie.

Bo problemem podstawowym jest to że w ogóle masz używać .net i podobnych
rozwiązań microsoftu (nawet jeśli istnieją implementacje pod unix).

Skoro mówisz o kosztach - kto podjął decyzje o używaniu tego badziewia i
dlaczego teraz Ty - a nie on - ponosić ma koszty i starać się je zredukować?

To tak samo jak próbowanie na siłę uruchamiać programy pod windows używając
wine.

wine fajna sprawa ale używać tego po to aby zaoszczędzić na windows - bez
przesady. 

W dniu 2010-05-19 13:55, Wojciech Puchar pisze:
> To co piszesz pozornie jest logiczne. Ale tylko pozornie.
> 
> Bo problemem podstawowym jest to że w ogóle masz używać .net i podobnych
> rozwiązań microsoftu (nawet jeśli istnieją implementacje pod unix).
> 
> Skoro mówisz o kosztach - kto podjął decyzje o używaniu tego badziewia i
> dlaczego teraz Ty - a nie on - ponosić ma koszty i starać się je zredukować?

ktoś komu zależało na czasie aby zainstnieć na rynku i miał na tyle
dobrą świadomośc że Java byłaby kompletną porażka dla naszego
rozwiazania (chociazby z uwagi na brak tyow wartościowych złożonych)
koncepcja byla dobra appliakcja wspierajaca produkt powstala bardzo
szybko a z czasem krytyczne jej skladniki ulegly optymalizacji do kodu
natywnego z tad rozwiazania hybrydowe.

> 
> To tak samo jak próbowanie na siłę uruchamiać programy pod windows używając
> wine.

znam dobrze dzialajace rozwiazanie serwerowe z wine w tle dzialajace na
linuxie obslugujace tyusiace wejsc na strone.

Dnia 19-05-2010 o 00:04:44 Wojciech Puchar  
<wojtek@wojtek.tensor.gdynia.pl> napisał(a):

>>> OpenBSD - dużo gadania o "bezpieczeństwie" które nie jest ani troche  
>>> większe
>>> niż w innych BSD, w końcu to zależy od tego jakie programy się  
>>> uruchamia.
>>> Błędów w kernelu skutkujących dziurami w żadnym BSD praktycznie nie  
>>> ma, jak
>>> są to jest święto.
>>>
>>> Poza tym - wydajność koszmarna.
>>
>> Do zastosowań sieciowych jest całkiem fajne. PF we FreeBSD jest dość
>> leciwy.
>
> Całkiem możliwe. Tyle że ja wole IPFW z FreeBSD od KAŻDEJ wersji PF.
>
> Ale znaleźliśmy JAKIEŚ zastosowanie do OpenBSD ;)
>
Sam niedawno zastanawialem sie by przejsc do Open, bo PF to jest to, co  
tygrysy lubia najbardziej. Nigdy mnie nie zawiodlo, nawet w starawej  
wersji, ktora jest na Free. I pomimo, ze sa braki do tego, co jest w  
najnowszych wersjach na Open, to mimo wszystko swietnie sie sprawdza. A  
wraz z ALTQ jest nie do pobicia ;-)



>>
>>> Więc co zostało. W razie jeśli nowe wersje FreeBSD będą robione już w  
>>> stylu
>>> "nowoczesnym" czyli byle jak najszybciej zawsze można będzie robić  
>>> backporty
>>> sterowników.
>>

Widze, ze posiadles tajemnicza umiejetnosc backportowania sterownikow i  
"Naczytałeś się głupot o żabach, a teraz na siłę próbujesz zainteresować  
tym innych" ;)

>> Jeśłi ma sprostać potrzebom rynku, tak właśnie powinno być rozwijane. I
>
> Rynek na tym polega że ma wielu klientów i wiele nisz rynkowych. Więc nie
> istnieje jedna potrzeba rynku.
>
>> bardzo dobrze, że tak właśnie to się dzieje.
> Co to jest "potrzeba rynku" w przypadku oprogramowania które jest za  
> darmo?

Nie jest za darmo. To, ze Ty nie placisz, nie oznacza, ze nikt nie placi.  
Placi sie za uslugi i support. Przyklad Red Hat ;-) Placa tez podatnicy,  
ktorzy lozyli kase na edukowanie tych, ktorzy zaczeli te projekty... A ze  
BSD byl zapoczatkowany w Berkley, to zaplacili za niego obywatele USA ;-)  
Placimy tez my, jako klienci firm, ktore wspieraja okreslony  
system/aplikacje. Wyobraz sobie, ze np. home.pl dotuje fundacje FreeBSD.  
Ty kupujesz w home.pl domene, przez co posrednio sam dotujesz dalszy  
rozwoj FreeBSD ;-) Przyklad moze chybiony, bo nie wiem, czy home chociaz  
centem dotuje FreeBSD, aczkolwiek sa firmy, ktore to robia.

Potrzeba rynku jestes nawet Ty sam, bo ciagle marudzisz o tym i tamtym.  
Oznacza to, ze czegos Ci brakuje i czegos potrzebujesz w danym systemie.  
Gdybys sypnal groszem, to znalezli by sie tacy, ktorzy na Twoja potrzebe  
by zareagowali i dopisali/poprawili to, czego Ty oczekujesz ;) Jesli  
znajdzie sie juz wieksza grupa skamlaczy, to wsrod nich bedzie taki, co  
sypnie groszem... albo sam cos takiego zaimplemenuje. I albo to udostepni  
innym skamlaczom, by wspolnie rozwijac dany projekt , albo bedzie zarabial  
na tym w postaci zamknietego oprogramowania...

Zamiast marudzic, sam moglbys wesprzec (skoro potrafisz programowac)  
rozwoj tego, co wg. Ciebie jest skopane, a nie tylko wmawiac wszystkim  
dookola, zeby kupowali Windowsy, portowac sterowniki na starocie i uzywac  
sprzetu z demobilu.

> koncepcja byla dobra appliakcja wspierajaca produkt powstala bardzo
> szybko a z czasem krytyczne jej skladniki ulegly optymalizacji do kodu
> natywnego z tad rozwiazania hybrydowe.

więc dalszą fazą byłoby optymalizacja po kolei wszystkiego i pozbycie się
.net

Nie oczekuj że kiedykolwiek to pod unix będzie naprawde dobre.
Zadnemu dobremu programiście za darmo nie chce się poświęcać czasu na oprogramowywanie
darmowego klona marnych rozwiązań (mówie o .net).

>> To tak samo jak próbowanie na siłę uruchamiać programy pod windows używając
>> wine.
> 
> znam dobrze dzialajace rozwiazanie serwerowe z wine w tle dzialajace na
> linuxie obslugujace tyusiace wejsc na strone.

Można na siłe. Tylko po co.

Tzn. inaczej. Czasami całkiem jest to do rzeczy, natomiast tylko wtedy jak
po prostu masz zarobić na tym GRUBĄ kasę. inaczej się babrać w tym nie
opłaca.

Jeśli będziesz to robić za małą kasę - to co pomyślą odbiorcy?

"No windows to świetne rozwiązanie generalnie choć ma pare drobnych wad
które można ulepszyć stosując prostymi dodatkami naszego podwykonawcy".

Czyli wychodzi że unix to taka łata na drobne niedoskonałości windows.
I tak już jest to odbierane. Skutek to marginalizacja i w dłuższym czasie -
"troche mniej" fatalne rozwiązania wciąż wdrażane.

Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
> Nie oczekuj że kiedykolwiek to pod unix będzie naprawde dobre.
> Zadnemu dobremu programiście za darmo nie chce się poświęcać czasu na oprogramowywanie
> darmowego klona marnych rozwiązań (mówie o .net).

Poproszę o 5 argumentów przemawiających za tym, że .Net jest marnym rozwiązaniem.

Ponc
-- 
Kto misiowi urwał ucho?

Dnia 20.05.2010 Tomasz Piłat <poncki-NOSPAM-USUN@irc.pl> napisał/a:

> Poproszę o 5 argumentów przemawiających za tym, że .Net jest marnym rozwiązaniem.

1. gdyż
2. bo
3. ssie
4. perl
5. złooo(tm)


BP, NMSP ;)

-- 
Paweł Małachowski

On Thu, 20 May 2010 10:58:36 +0000 (UTC), Tomasz Piłat
<poncki-NOSPAM-USUN@irc.pl> wrote:

> Poproszę o 5 argumentów przemawiających za tym, że .Net jest marnym rozwiązaniem.

 Używają go np. banki ;)

 r.
-- 
_________________________________________________________________
robert rędziak     e36/5 323ti     mailto:giekao-at-gmail-dot-com

   I hope they don't fart at Greenpeace. That's bad for Gaia.

W dniu 2010-05-20 12:58, Tomasz Piłat pisze:
> Poproszę o 5 argumentów przemawiających za tym, że .Net jest marnym rozwiązaniem.

GC uniemożliwia skalowalność liniową aplikacji wielowątkowych. Przy
aplikacjach przetwarzajacych duże ilości danych nawet napisanych
metodami lockfree skalowalność kończy się przy ~2 .. 3 wątkach, powyżej
GC degrduje wydajność sprzatając ciagle dane, a to wynika z modelu
sprzatania - "stop the world" i skanowania calości danych i odznaczania
"zyjacych" obiektów.

arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
> GC uniemożliwia skalowalność liniową aplikacji wielowątkowych.
[...]

Wojtka Puchara prosiłem i tylko jego.

Ponc
PS Zrobić dobre GC wcale nie jest łatwo, tak na marginesie.
-- 
Kto misiowi urwał ucho?

W dniu 2010-05-20 22:40, Tomasz Piłat pisze:
> arturbac <artur_no_spam@no_spam.ebasoft.com.pl> wrote:
>> GC uniemożliwia skalowalność liniową aplikacji wielowątkowych.
> [...]
> 
> Wojtka Puchara prosiłem i tylko jego.

Na grupie dyskusyjnej ?

> PS Zrobić dobre GC wcale nie jest łatwo, tak na marginesie.

No i masz odpowiedź dlaczego to gówniane rozwiązanie.
PS: Poprawnie napisany GC istnieje puki co w teorii.

> Ponc
> PS Zrobić dobre GC wcale nie jest łatwo, tak na marginesie.
Zacznijmy od tego że sam pomysł "garbage collector" świadczy o śmieszności
reszty rozwiązania. Krótko mówiąc - nie programista ale system ma się
domyślać co jest w pamięci potrzebne a co nie.

Wojciech Puchar pisze:

> Zacznijmy od tego że sam pomysł "garbage collector" świadczy o
> śmieszności reszty rozwiązania. Krótko mówiąc - nie programista ale
> system ma się domyślać co jest w pamięci potrzebne a co nie.

...tylko tak na wszelki wypadek, żeby nie było zaskoczenia - mam zamiar
od czasu do czasu cytować te śliczności, które wypisujesz, z podaniem
nazwiska.

Jubal (Boże chroń Puchara niewinne ofiary.)

-- 
[ Miroslaw L Baran | jabber id: baran-at-hell-pl | key-id: FC494FC4 | 0101010 ]

                    A Smith and Wesson beats four aces.